Changelog Analyzer
Analyze all code changes between two git commits and produce a ranked summary of improvements and optimizations based on actual code diffs, not commit messages.
Parameters
- Start commit: The earliest commit hash (inclusive). Default:
e0be0387a636a93a062cee621fd78b83dfccb06e
- End commit: The latest commit. Default:
HEAD
If the user specifies a different range, use their values.
Workflow
Step 1: Enumerate commits and changed files
# List all commits in range (inclusive of start)
git log --oneline <start>~1..HEAD
# Get overall stats
git diff --stat <start>~1..HEAD
Step 2: Analyze code diffs in batches
The diff may be very large. Process it in logical batches by directory or feature area:
# Get diff for a specific path
git diff <start>~1..HEAD -- <path>
# Or per-commit diffs when granularity matters
git show --stat <commit-hash>
git show <commit-hash> -- <file>
Key analysis areas (check each):
apps/web/src/components/ — UI components, UX improvements
apps/web/src/services/ — Service layer, storage, transcription
apps/web/src/core/ and apps/web/src/lib/ — Core logic, utilities
apps/web/src/hooks/ — React hooks, state management
apps/web/src/stores/ — Zustand stores, state architecture
apps/web/src/types/ — Type definitions, data model changes
apps/web/src/app/ — Pages, routes, API endpoints
packages/ — Shared packages
- Config files, CI/CD, build system
Step 3: Classify each change
For each meaningful change found in the diffs, classify it into one of these categories:
| Category |
Icon |
Description |
| New Feature |
✨ |
Entirely new capability added |
| Performance |
⚡ |
Speed, memory, or rendering optimization |
| Bug Fix |
🐛 |
Corrected broken or incorrect behavior |
| UX Improvement |
🎨 |
Better user experience, UI polish |
| Refactor |
♻️ |
Code restructuring without behavior change |
| Architecture |
🏗️ |
Structural or design pattern improvement |
| DX / Tooling |
🔧 |
Developer experience, build, CI/CD |
| i18n |
🌐 |
Internationalization, localization |
| Security |
🔒 |
Security hardening |
| Cleanup |
🧹 |
Dead code removal, dependency cleanup |
Step 4: Determine importance
Rate each change on impact (1-5):
| Score |
Criteria |
| 5 |
Core feature, affects most users, or prevents data loss |
| 4 |
Significant feature or major UX/perf improvement |
| 3 |
Notable improvement, moderate user impact |
| 2 |
Minor enhancement, affects subset of users |
| 1 |
Cosmetic, cleanup, or internal-only change |
Step 5: Produce the report
Output a markdown report with this structure:
# Changelog: <start-hash-short>..<end-hash-short>
**Period**: <first-commit-date> → <last-commit-date>
**Commits**: <count> | **Files changed**: <count> | **+<insertions> / -<deletions>**
---
## Key Changes (by importance)
### ⭐⭐⭐⭐⭐ Critical / High Impact
#### ✨ [Feature/Change Title]
- **What changed**: Concise description based on actual code diff
- **Files**: List of key files modified
- **Impact**: Why this matters to users or the codebase
### ⭐⭐⭐⭐ Significant
...
### ⭐⭐⭐ Notable
...
### ⭐⭐ Minor
...
### ⭐ Cosmetic / Internal
...
---
## Summary Statistics
| Category | Count |
|----------|-------|
| New Features | X |
| Performance | X |
| Bug Fixes | X |
| ... | ... |
Important Rules
- Read actual diffs — Never rely solely on commit messages. Always
git diff or git show to see what really changed.
- Group related commits — Multiple commits may contribute to a single logical change. Merge them into one entry.
- Be specific — Reference actual function names, components, or files that changed.
- Skip noise — Ignore auto-generated files (lock files, build artifacts) and trivial whitespace changes.
- Use subagents for parallelism — When the diff is large, launch multiple explore/generalPurpose subagents to analyze different directories concurrently.
- Output in Chinese — The final report should be written in Chinese (中文), matching the user's language preference.
1---2name: changelog-analyzer3description: Analyze git commits in a range by examining actual code diffs (not commit titles) and produce a ranked list of improvements and optimizations. Use when the user wants a changelog, wants to summarize recent changes, asks what changed since a commit, or wants to review project progress.4---56# Changelog Analyzer78Analyze all code changes between two git commits and produce a ranked summary of improvements and optimizations based on **actual code diffs**, not commit messages.910## Parameters1112- **Start commit**: The earliest commit hash (inclusive). Default: `e0be0387a636a93a062cee621fd78b83dfccb06e`13- **End commit**: The latest commit. Default: `HEAD`1415If the user specifies a different range, use their values.1617## Workflow1819### Step 1: Enumerate commits and changed files2021```bash22# List all commits in range (inclusive of start)23git log --oneline <start>~1..HEAD2425# Get overall stats26git diff --stat <start>~1..HEAD27```2829### Step 2: Analyze code diffs in batches3031The diff may be very large. Process it in logical batches by directory or feature area:3233```bash34# Get diff for a specific path35git diff <start>~1..HEAD -- <path>3637# Or per-commit diffs when granularity matters38git show --stat <commit-hash>39git show <commit-hash> -- <file>40```4142**Key analysis areas** (check each):431. `apps/web/src/components/` — UI components, UX improvements442. `apps/web/src/services/` — Service layer, storage, transcription453. `apps/web/src/core/` and `apps/web/src/lib/` — Core logic, utilities464. `apps/web/src/hooks/` — React hooks, state management475. `apps/web/src/stores/` — Zustand stores, state architecture486. `apps/web/src/types/` — Type definitions, data model changes497. `apps/web/src/app/` — Pages, routes, API endpoints508. `packages/` — Shared packages519. Config files, CI/CD, build system5253### Step 3: Classify each change5455For each meaningful change found in the diffs, classify it into one of these categories:5657| Category | Icon | Description |58|----------|------|-------------|59| **New Feature** | ✨ | Entirely new capability added |60| **Performance** | ⚡ | Speed, memory, or rendering optimization |61| **Bug Fix** | 🐛 | Corrected broken or incorrect behavior |62| **UX Improvement** | 🎨 | Better user experience, UI polish |63| **Refactor** | ♻️ | Code restructuring without behavior change |64| **Architecture** | 🏗️ | Structural or design pattern improvement |65| **DX / Tooling** | 🔧 | Developer experience, build, CI/CD |66| **i18n** | 🌐 | Internationalization, localization |67| **Security** | 🔒 | Security hardening |68| **Cleanup** | 🧹 | Dead code removal, dependency cleanup |6970### Step 4: Determine importance7172Rate each change on impact (1-5):7374| Score | Criteria |75|-------|----------|76| 5 | Core feature, affects most users, or prevents data loss |77| 4 | Significant feature or major UX/perf improvement |78| 3 | Notable improvement, moderate user impact |79| 2 | Minor enhancement, affects subset of users |80| 1 | Cosmetic, cleanup, or internal-only change |8182### Step 5: Produce the report8384Output a markdown report with this structure:8586```markdown87# Changelog: <start-hash-short>..<end-hash-short>8889**Period**: <first-commit-date> → <last-commit-date>90**Commits**: <count> | **Files changed**: <count> | **+<insertions> / -<deletions>**9192---9394## Key Changes (by importance)9596### ⭐⭐⭐⭐⭐ Critical / High Impact9798#### ✨ [Feature/Change Title]99- **What changed**: Concise description based on actual code diff100- **Files**: List of key files modified101- **Impact**: Why this matters to users or the codebase102103### ⭐⭐⭐⭐ Significant104105...106107### ⭐⭐⭐ Notable108109...110111### ⭐⭐ Minor112113...114115### ⭐ Cosmetic / Internal116117...118119---120121## Summary Statistics122123| Category | Count |124|----------|-------|125| New Features | X |126| Performance | X |127| Bug Fixes | X |128| ... | ... |129```130131## Important Rules1321331. **Read actual diffs** — Never rely solely on commit messages. Always `git diff` or `git show` to see what really changed.1342. **Group related commits** — Multiple commits may contribute to a single logical change. Merge them into one entry.1353. **Be specific** — Reference actual function names, components, or files that changed.1364. **Skip noise** — Ignore auto-generated files (lock files, build artifacts) and trivial whitespace changes.1375. **Use subagents for parallelism** — When the diff is large, launch multiple explore/generalPurpose subagents to analyze different directories concurrently.1386. **Output in Chinese** — The final report should be written in Chinese (中文), matching the user's language preference.