feat(analytics): anonymous LLM provider/model usage analytics

.claude/skills/close-task-commit-push-pr/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: close-task-commit-push-pr
+description: Close the active backlog task (detected from branch name), commit all changes, push to remote, and open a pull request. Use when the user says "close task and ship it", "close task commit push pr", or invokes /close-task-commit-push-pr.
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git commit:*), Bash(git push:*), Bash(git branch:*), Bash(git checkout:*), Bash(gh pr create:*), mcp__backlog__task_edit, mcp__backlog__task_complete, mcp__backlog__task_view
+---
+
+# Close Task, Commit, Push & PR
+
+## Context
+
+- Current git status: !`git status`
+- Current git diff (staged and unstaged changes): !`git diff HEAD`
+- Current branch: !`git branch --show-current`
+- Main branch: !`git rev-parse --verify main 2>/dev/null && echo main || echo master`
+- Recent commits: !`git log --oneline -10`
+
+## Your task
+
+Close the active backlog task, commit all changes, push, and open a pull request.
+
+### Step 0 — Identify the task
+
+- Extract the task ID from the current branch name (e.g. `feature/task-113-split-css-modules` → `task-113`).
+- If no task ID is found in the branch name, ask the user which task to close.
+
+### Step 1 — Close the backlog task
+
+Close the task **before** committing so the task file changes are included in the commit and PR.
+
+- Use `mcp__backlog__task_view` to read the task details (title, acceptance criteria).
+- Use `mcp__backlog__task_edit` to:
+  - Set status to `Done`
+  - Check off all acceptance criteria that were completed (review the diff to determine which ones)
+  - Write a `finalSummary` that concisely describes what was implemented
+- Use `mcp__backlog__task_complete` to move the task to the completed folder.
+
+### Step 2 — Analyze changes and plan commits
+
+Before committing, analyze `git status` and `git diff HEAD` to identify logically distinct groups of changes. Group by feature or concern — for example:
+
+- New files that form a self-contained module → one commit
+- Modifications to an existing file that depend on the new module → separate commit
+- Task/backlog file changes → include in the final commit (or a dedicated chore commit)
+
+Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.
+
+### Step 3 — Commit
+
+- Create one commit per logical group identified above. Stage only the files for that group using explicit file names (never `git add -A`; never stage `.env` or credential files).
+- Write a clean, descriptive commit message for each commit using conventional commits style.
+- End every commit message with:
+  `Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>`
+- Use a HEREDOC to pass the commit message for correct formatting.
+- **Include the closed task file** in the final commit.
+
+### Step 4 — Push
+
+- If the current branch is `main` or `master`, create a new feature branch first (use a descriptive name based on the changes).
+- Push the branch to origin with `-u` to set upstream tracking.
+
+### Step 5 — Pull Request
+
+- Create a PR using `gh pr create` targeting the main branch.
+- Keep the PR title short (under 70 characters), using conventional commit style.
+- Use a HEREDOC for the PR body with this format:
+
+```
+## Summary
+<1-3 bullet points describing the changes>
+
+## Test plan
+- [ ] <testing checklist items>
+
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+```
+
+### Step 6 — Update task with PR reference
+
+- Now that you have the PR number, use `mcp__backlog__task_edit` to append the PR URL/number to the `finalSummary`.
+
+### Step 7 — Amend commit with updated task file
+
+- Stage the updated task file and amend the last commit to include the PR reference: `git commit --amend --no-edit` then `git push --force-with-lease`.
+
+### Step 8 — Report
+
+- Print the PR URL and confirm the task was closed.
+
+## Rules
+
+- Do all steps in as few messages as possible. Parallelize independent tool calls.
+- Do not read or explore code beyond what git provides in the context above.
+- Do not use interactive git flags (`-i`).
+- Never force-push or amend existing commits.
+- If a pre-commit hook fails, fix the issue and create a NEW commit (do not amend).

.claude/skills/git-commit-push-pr/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: git-commit-push-pr
+description: Commit all changes, push to remote, and open a pull request in one go. Use when the user says "commit push pr", "ship it", "open a pr", or invokes /git-commit-push-pr.
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git commit:*), Bash(git push:*), Bash(git branch:*), Bash(git checkout:*), Bash(gh pr create:*)
+---
+
+# Git Commit, Push & PR
+
+## Context
+
+- Current git status: !`git status`
+- Current git diff (staged and unstaged changes): !`git diff HEAD`
+- Current branch: !`git branch --show-current`
+- Main branch: !`git rev-parse --verify main 2>/dev/null && echo main || echo master`
+- Recent commits: !`git log --oneline -10`
+
+## Your task
+
+Review the changes in the repo and ship them as a pull request in one go.
+
+### Step 1 — Analyze changes and plan commits
+
+Before committing, analyze `git status` and `git diff HEAD` to identify logically distinct groups of changes. Group by feature or concern — for example:
+
+- New files that form a self-contained module → one commit
+- Modifications to an existing file that depend on the new module → separate commit
+- Config or tooling changes → separate commit
+
+Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.
+
+### Step 2 — Commit
+
+- Create one commit per logical group identified above. Stage only the files for that group using explicit file names (never `git add -A`; never stage `.env` or credential files).
+- Write a clean, descriptive commit message for each commit using conventional commits style.
+- End every commit message with:
+  `Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>`
+- Use a HEREDOC to pass the commit message for correct formatting.
+
+### Step 3 — Push
+
+- If the current branch is `main` or `master`, create a new feature branch first (use a descriptive name based on the changes).
+- Push the branch to origin with `-u` to set upstream tracking.
+
+### Step 4 — Pull Request
+
+- Create a PR using `gh pr create` targeting the main branch.
+- Keep the PR title short (under 70 characters), using conventional commit style.
+- Use a HEREDOC for the PR body with this format:
+
+```
+## Summary
+<1-3 bullet points describing the changes>
+
+## Test plan
+- [ ] <testing checklist items>
+
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+```
+
+### Step 5 — Report
+
+- Print the PR URL so the user can see it.
+
+## Rules
+
+- Do all steps in as few messages as possible. Parallelize independent tool calls.
+- Do not read or explore code beyond what git provides in the context above.
+- Do not use interactive git flags (`-i`).
+- Never force-push or amend existing commits.
+- If a pre-commit hook fails, fix the issue and create a NEW commit (do not amend).

.claude/skills/review/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: review
+description: Review local code changes for bugs, regressions, missing tests, and pragmatic improvements. Use when the user asks to review the current changes from `git status`, or to review a specific backlog task by id such as `task-65` or `TASK-65`. Also trigger when the user says things like "review", "review current changes", "check my changes", "look over the diff", or "review task-42".
+---
+
+# Review
+
+## Overview
+
+Review the current local changes or the implementation tied to a backlog task id and report concrete findings, not a changelog. Treat this as a code review unless the user explicitly asks for edits.
+
+## Workflow
+
+1. Resolve the review target.
+If the prompt includes a backlog task id, locate the task markdown in `backlog/tasks/` first, then `backlog/completed/` if needed. Read the description, acceptance criteria, and referenced files. If no task id is given, start from `git status --short` and review the current local changes directly.
+
+2. Build review scope from local context.
+Check `git status --short`, inspect the diff for files related to the task, and read surrounding code where behavior is affected. Prefer `rg` and targeted `git diff -- <path>` over broad scans.
+
+3. Review for defects and regressions.
+Prioritize:
+- broken behavior versus the task intent
+- stale callers or UI paths left behind after refactors
+- contract mismatches across main/preload/renderer/shared code
+- silent failure handling and misleading fallback behavior
+- missing or weak tests for the changed behavior
+- unnecessary performance regressions or duplicate work
+
+4. Verify when useful.
+Run focused tests for the touched area if they are available and cheap. Mention clearly when verification is blocked or when broader typecheck/test failures are unrelated.
+
+## Output
+
+Report findings first, ordered by severity. For each finding:
+- state the severity
+- describe the bug/risk or improvement
+- include clickable file references with line numbers when available
+- explain the user-visible or maintenance impact briefly
+
+After findings, include:
+- open questions or assumptions if any
+- a brief note on verification performed
+
+If no findings are discovered, say that explicitly and mention residual risk or missing coverage.
+
+## Prompt Shape
+
+Interpret prompts like `review`, `review current changes`, or `review the changes from git status` as a request to review the current working tree. Interpret prompts like `task-56`, `review task-56`, or `review task-56 and report any issues/bugs or possible improvements` as a review of the local changes associated with that task.

.claude/skills/start-task/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: start-task
+description: Create a feature branch for a backlog task, switch to it, and start implementation. Use when the user says "start task-123", "work on task-123", "implement task-123", or invokes /start-task with a task ID.
+allowed-tools: Bash(git checkout:*), Bash(git branch:*), Bash(git status:*), Bash(git pull:*), Bash(git stash:*), Bash(npm run lint:*), Bash(npm run typecheck:*), Bash(npm test:*), Bash(npm run build*), Bash(npx playwright test:*), mcp__backlog__task_view, mcp__backlog__task_edit, mcp__backlog__task_search, mcp__backlog__task_list
+---
+
+# Start Task
+
+## Context
+
+- Current branch: !`git branch --show-current`
+- Working tree status: !`git status --short`
+- Existing branches: !`git branch --list 'feature/task-*'`
+
+## Your task
+
+Create a feature branch for a backlog task and begin implementation.
+
+The user will provide a task ID (e.g. `task-123` or `123`). If no task ID is provided, check the argument `$ARGUMENTS` for the task reference.
+
+### Step 1 — Load the task
+
+- Normalize the input: if the user gave just a number like `123`, treat it as `task-123`.
+- Use `mcp__backlog__task_view` to read the full task details: title, description, acceptance criteria, and any referenced files.
+- If the task is not found, use `mcp__backlog__task_search` to locate it.
+- Print a brief summary of the task for the user.
+
+### Step 2 — Ensure a clean working tree
+
+- Check `git status`. If there are uncommitted changes, warn the user and ask whether to stash them before proceeding.
+- Ensure we are on the main branch. If not, ask the user if they want to switch.
+
+### Step 3 — Create and switch to a feature branch
+
+- Pull latest changes on main: `git pull --rebase`.
+- Derive a branch name from the task: `feature/task-{id}-{slugified-title}` (lowercase, hyphens, max ~60 chars).
+  - Example: task 113 "Split app.css into native CSS modules" → `feature/task-113-split-css-modules`
+- Create and switch to the branch: `git checkout -b <branch-name>`.
+
+### Step 4 — Mark the task as in-progress
+
+- Use `mcp__backlog__task_edit` to set the task status to `In Progress`.
+
+### Step 5 — Plan and implement
+
+- Analyze the task description and acceptance criteria carefully.
+- Read all files referenced in the task, plus any related code you need to understand.
+- Create a plan and present it to the user for approval before writing code.
+- Once approved, implement the changes following the project's patterns and conventions.
+- After implementation, run the full verification suite:
+  ```bash
+  npm run lint && npm run typecheck && npm test && npm run build:app && npx playwright test
+  ```
+- Fix any issues found by the verification suite.
+
+### Step 6 — Report
+
+- Summarize what was implemented and which acceptance criteria were addressed.
+- Remind the user they can use `/close-task-commit-push-pr` when ready to ship.
+
+## Rules
+
+- Always create the branch from an up-to-date main branch.
+- Never start implementation without showing the plan to the user first.
+- Follow existing code patterns and conventions in the project.
+- Do not use interactive git flags (`-i`).
+- If the working tree is dirty, never silently discard changes.

.gitignore

@@ -1,5 +1,6 @@
 .env
 build/**
+.kotlin/
 .gradle
 .intellijPlatform
 .idea

CHANGELOG.md

@@ -2,6 +2,11 @@ so # Changelog
 
 All notable changes to this project will be documented in this file.
 
+## [Unreleased]
+
+### Added
+- Anonymous LLM provider/model usage analytics (opt-out). Helps guide which providers and models receive engineering investment. The plugin sends a minimal payload — anonymous install ID (UUID), per-launch session ID, plugin version, IDE version, LLM provider name, LLM model name — when you run a prompt or change models. **Never sent**: prompt text, response text, file content, file paths, project names, conversation history, API keys, or anything that could identify you. A first-launch notification asks for consent; you can disable it any time in *Settings → DevoxxGenie → General*.
+
 ## [1.4.1]
 
 ### Updated

README.md

@@ -417,6 +417,25 @@ It is recommended to use the publishPlugin task for releasing the plugin
 Enjoy!
 
 
+## Privacy & Anonymous Usage Analytics
+
+To guide which LLM providers and models receive engineering investment, DevoxxGenie collects **anonymous** usage data when you run a prompt or change models.
+
+**What is sent:**
+- An anonymous install ID (UUID), generated once and stored locally
+- A per-launch session ID (random 10-digit number)
+- Plugin version and IDE version
+- LLM provider name (e.g. `anthropic`, `ollama`)
+- LLM model name (e.g. `claude-3-5-sonnet`)
+
+**What is never sent:**
+- Prompt text, response text, conversation history
+- File content, file paths, project name, git remote
+- API keys, credentials, user name, email
+- Token counts or cost data
+
+A first-launch notification asks for your consent before any data is sent. You can change this at any time in **Settings → DevoxxGenie → General**.
+
 ## Contribute
 
 **[📖 Contributing Guide](https://genie.devoxx.com/docs/contributing)**