Skip to content

Commit 3ec0ac2

Browse files
stephanjstephanj
authored
Merge pull request #1005 from devoxx/feature/llm-usage-analytics
feat(analytics): anonymous LLM provider/model usage analytics
2 parents 28f9c95 + 0f1a5e4 commit 3ec0ac2

24 files changed

Lines changed: 1470 additions & 16 deletions

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

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
---
2+
name: close-task-commit-push-pr
3+
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.
4+
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
5+
---
6+
7+
# Close Task, Commit, Push & PR
8+
9+
## Context
10+
11+
- Current git status: !`git status`
12+
- Current git diff (staged and unstaged changes): !`git diff HEAD`
13+
- Current branch: !`git branch --show-current`
14+
- Main branch: !`git rev-parse --verify main 2>/dev/null && echo main || echo master`
15+
- Recent commits: !`git log --oneline -10`
16+
17+
## Your task
18+
19+
Close the active backlog task, commit all changes, push, and open a pull request.
20+
21+
### Step 0 — Identify the task
22+
23+
- Extract the task ID from the current branch name (e.g. `feature/task-113-split-css-modules` → `task-113`).
24+
- If no task ID is found in the branch name, ask the user which task to close.
25+
26+
### Step 1 — Close the backlog task
27+
28+
Close the task **before** committing so the task file changes are included in the commit and PR.
29+
30+
- Use `mcp__backlog__task_view` to read the task details (title, acceptance criteria).
31+
- Use `mcp__backlog__task_edit` to:
32+
- Set status to `Done`
33+
- Check off all acceptance criteria that were completed (review the diff to determine which ones)
34+
- Write a `finalSummary` that concisely describes what was implemented
35+
- Use `mcp__backlog__task_complete` to move the task to the completed folder.
36+
37+
### Step 2 — Analyze changes and plan commits
38+
39+
Before committing, analyze `git status` and `git diff HEAD` to identify logically distinct groups of changes. Group by feature or concern — for example:
40+
41+
- New files that form a self-contained module → one commit
42+
- Modifications to an existing file that depend on the new module → separate commit
43+
- Task/backlog file changes → include in the final commit (or a dedicated chore commit)
44+
45+
Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.
46+
47+
### Step 3 — Commit
48+
49+
- 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).
50+
- Write a clean, descriptive commit message for each commit using conventional commits style.
51+
- End every commit message with:
52+
`Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>`
53+
- Use a HEREDOC to pass the commit message for correct formatting.
54+
- **Include the closed task file** in the final commit.
55+
56+
### Step 4 — Push
57+
58+
- If the current branch is `main` or `master`, create a new feature branch first (use a descriptive name based on the changes).
59+
- Push the branch to origin with `-u` to set upstream tracking.
60+
61+
### Step 5 — Pull Request
62+
63+
- Create a PR using `gh pr create` targeting the main branch.
64+
- Keep the PR title short (under 70 characters), using conventional commit style.
65+
- Use a HEREDOC for the PR body with this format:
66+
67+
```
68+
## Summary
69+
<1-3 bullet points describing the changes>
70+
71+
## Test plan
72+
- [ ] <testing checklist items>
73+
74+
🤖 Generated with [Claude Code](https://claude.com/claude-code)
75+
```
76+
77+
### Step 6 — Update task with PR reference
78+
79+
- Now that you have the PR number, use `mcp__backlog__task_edit` to append the PR URL/number to the `finalSummary`.
80+
81+
### Step 7 — Amend commit with updated task file
82+
83+
- 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`.
84+
85+
### Step 8 — Report
86+
87+
- Print the PR URL and confirm the task was closed.
88+
89+
## Rules
90+
91+
- Do all steps in as few messages as possible. Parallelize independent tool calls.
92+
- Do not read or explore code beyond what git provides in the context above.
93+
- Do not use interactive git flags (`-i`).
94+
- Never force-push or amend existing commits.
95+
- 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‎

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
name: git-commit-push-pr
3+
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.
4+
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:*)
5+
---
6+
7+
# Git Commit, Push & PR
8+
9+
## Context
10+
11+
- Current git status: !`git status`
12+
- Current git diff (staged and unstaged changes): !`git diff HEAD`
13+
- Current branch: !`git branch --show-current`
14+
- Main branch: !`git rev-parse --verify main 2>/dev/null && echo main || echo master`
15+
- Recent commits: !`git log --oneline -10`
16+
17+
## Your task
18+
19+
Review the changes in the repo and ship them as a pull request in one go.
20+
21+
### Step 1 — Analyze changes and plan commits
22+
23+
Before committing, analyze `git status` and `git diff HEAD` to identify logically distinct groups of changes. Group by feature or concern — for example:
24+
25+
- New files that form a self-contained module → one commit
26+
- Modifications to an existing file that depend on the new module → separate commit
27+
- Config or tooling changes → separate commit
28+
29+
Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.
30+
31+
### Step 2 — Commit
32+
33+
- 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).
34+
- Write a clean, descriptive commit message for each commit using conventional commits style.
35+
- End every commit message with:
36+
`Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>`
37+
- Use a HEREDOC to pass the commit message for correct formatting.
38+
39+
### Step 3 — Push
40+
41+
- If the current branch is `main` or `master`, create a new feature branch first (use a descriptive name based on the changes).
42+
- Push the branch to origin with `-u` to set upstream tracking.
43+
44+
### Step 4 — Pull Request
45+
46+
- Create a PR using `gh pr create` targeting the main branch.
47+
- Keep the PR title short (under 70 characters), using conventional commit style.
48+
- Use a HEREDOC for the PR body with this format:
49+
50+
```
51+
## Summary
52+
<1-3 bullet points describing the changes>
53+
54+
## Test plan
55+
- [ ] <testing checklist items>
56+
57+
🤖 Generated with [Claude Code](https://claude.com/claude-code)
58+
```
59+
60+
### Step 5 — Report
61+
62+
- Print the PR URL so the user can see it.
63+
64+
## Rules
65+
66+
- Do all steps in as few messages as possible. Parallelize independent tool calls.
67+
- Do not read or explore code beyond what git provides in the context above.
68+
- Do not use interactive git flags (`-i`).
69+
- Never force-push or amend existing commits.
70+
- If a pre-commit hook fails, fix the issue and create a NEW commit (do not amend).

‎.claude/skills/review/SKILL.md‎

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
---
2+
name: review
3+
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".
4+
---
5+
6+
# Review
7+
8+
## Overview
9+
10+
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.
11+
12+
## Workflow
13+
14+
1. Resolve the review target.
15+
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.
16+
17+
2. Build review scope from local context.
18+
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.
19+
20+
3. Review for defects and regressions.
21+
Prioritize:
22+
- broken behavior versus the task intent
23+
- stale callers or UI paths left behind after refactors
24+
- contract mismatches across main/preload/renderer/shared code
25+
- silent failure handling and misleading fallback behavior
26+
- missing or weak tests for the changed behavior
27+
- unnecessary performance regressions or duplicate work
28+
29+
4. Verify when useful.
30+
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.
31+
32+
## Output
33+
34+
Report findings first, ordered by severity. For each finding:
35+
- state the severity
36+
- describe the bug/risk or improvement
37+
- include clickable file references with line numbers when available
38+
- explain the user-visible or maintenance impact briefly
39+
40+
After findings, include:
41+
- open questions or assumptions if any
42+
- a brief note on verification performed
43+
44+
If no findings are discovered, say that explicitly and mention residual risk or missing coverage.
45+
46+
## Prompt Shape
47+
48+
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‎

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
name: start-task
3+
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.
4+
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
5+
---
6+
7+
# Start Task
8+
9+
## Context
10+
11+
- Current branch: !`git branch --show-current`
12+
- Working tree status: !`git status --short`
13+
- Existing branches: !`git branch --list 'feature/task-*'`
14+
15+
## Your task
16+
17+
Create a feature branch for a backlog task and begin implementation.
18+
19+
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.
20+
21+
### Step 1 — Load the task
22+
23+
- Normalize the input: if the user gave just a number like `123`, treat it as `task-123`.
24+
- Use `mcp__backlog__task_view` to read the full task details: title, description, acceptance criteria, and any referenced files.
25+
- If the task is not found, use `mcp__backlog__task_search` to locate it.
26+
- Print a brief summary of the task for the user.
27+
28+
### Step 2 — Ensure a clean working tree
29+
30+
- Check `git status`. If there are uncommitted changes, warn the user and ask whether to stash them before proceeding.
31+
- Ensure we are on the main branch. If not, ask the user if they want to switch.
32+
33+
### Step 3 — Create and switch to a feature branch
34+
35+
- Pull latest changes on main: `git pull --rebase`.
36+
- Derive a branch name from the task: `feature/task-{id}-{slugified-title}` (lowercase, hyphens, max ~60 chars).
37+
- Example: task 113 "Split app.css into native CSS modules" → `feature/task-113-split-css-modules`
38+
- Create and switch to the branch: `git checkout -b <branch-name>`.
39+
40+
### Step 4 — Mark the task as in-progress
41+
42+
- Use `mcp__backlog__task_edit` to set the task status to `In Progress`.
43+
44+
### Step 5 — Plan and implement
45+
46+
- Analyze the task description and acceptance criteria carefully.
47+
- Read all files referenced in the task, plus any related code you need to understand.
48+
- Create a plan and present it to the user for approval before writing code.
49+
- Once approved, implement the changes following the project's patterns and conventions.
50+
- After implementation, run the full verification suite:
51+
```bash
52+
npm run lint && npm run typecheck && npm test && npm run build:app && npx playwright test
53+
```
54+
- Fix any issues found by the verification suite.
55+
56+
### Step 6 — Report
57+
58+
- Summarize what was implemented and which acceptance criteria were addressed.
59+
- Remind the user they can use `/close-task-commit-push-pr` when ready to ship.
60+
61+
## Rules
62+
63+
- Always create the branch from an up-to-date main branch.
64+
- Never start implementation without showing the plan to the user first.
65+
- Follow existing code patterns and conventions in the project.
66+
- Do not use interactive git flags (`-i`).
67+
- If the working tree is dirty, never silently discard changes.

‎.gitignore‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,6 @@
11
.env
22
build/**
3+
.kotlin/
34
.gradle
45
.intellijPlatform
56
.idea

‎CHANGELOG.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,11 @@ so # Changelog
22

33
All notable changes to this project will be documented in this file.
44

5+
## [Unreleased]
6+
7+
### Added
8+
- 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*.
9+
510
## [1.4.1]
611

712
### Updated

‎README.md‎

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -417,6 +417,25 @@ It is recommended to use the publishPlugin task for releasing the plugin
417417
Enjoy!
418418

419419

420+
## Privacy & Anonymous Usage Analytics
421+
422+
To guide which LLM providers and models receive engineering investment, DevoxxGenie collects **anonymous** usage data when you run a prompt or change models.
423+
424+
**What is sent:**
425+
- An anonymous install ID (UUID), generated once and stored locally
426+
- A per-launch session ID (random 10-digit number)
427+
- Plugin version and IDE version
428+
- LLM provider name (e.g. `anthropic`, `ollama`)
429+
- LLM model name (e.g. `claude-3-5-sonnet`)
430+
431+
**What is never sent:**
432+
- Prompt text, response text, conversation history
433+
- File content, file paths, project name, git remote
434+
- API keys, credentials, user name, email
435+
- Token counts or cost data
436+
437+
A first-launch notification asks for your consent before any data is sent. You can change this at any time in **Settings → DevoxxGenie → General**.
438+
420439
## Contribute
421440

422441
**[📖 Contributing Guide](https://genie.devoxx.com/docs/contributing)**

0 commit comments

Comments
 (0)