Changelog Generator
Use This Skill When
- Preparing release notes for a new product version
- Creating weekly or monthly product update summaries
- Documenting changes for customers or stakeholders
- Writing app store changelog submissions
- Generating update notifications for users
- Maintaining public changelog or product update pages
- Creating internal release documentation
- Need to transform commits into customer-facing language
When NOT to Use
- Internal developer documentation (keep technical commit language)
- When commits already have clear user-facing descriptions
- For non-git version control systems
- When detailed technical accuracy is required for developers
- For automated CI/CD commit logs (use raw commits instead)
Context: Changelog Maturity
Undeveloped: Raw git commits listed, technical jargon, unclear for customers.
Target: Commits categorized by type, translated to user language, grouped logically, professional formatting.
Optimized: Polished changelog with strategic storytelling, emphasis on customer impact, brand voice, multimedia integration.
Core Principle
Users deserve clear, accessible changelogs that celebrate product improvements. Transform technical commits into customer language that highlights impact, not implementation.
Instructions
Step 1: Gather Commit History
Identify the scope:
| Scope Type |
Example |
Use Case |
| Date Range |
"March 1–15" |
Weekly/monthly updates |
| Version Range |
"v2.4.0 to v2.5.0" |
Release-specific |
| Time Period |
"Last 7 days" |
Recent changes |
| Branch |
"main since last release" |
Staged features |
Command pattern (provide to user):
Get all commits from [DATE] to [DATE]
or
Get all commits between version [V1] and [V2]
or
Get all commits from the past [N] days
Step 2: Categorize Changes
Standard Categories:
| Category |
Indicators |
Icon |
| Features |
"feat:", new functionality, user-facing |
✨ |
| Improvements |
"perf:", "improve", speed, UX enhancements |
🔧 |
| Bug Fixes |
"fix:", "resolved", issues, errors |
🐛 |
| Breaking Changes |
"BREAKING", incompatible changes |
⚠️ |
| Security |
"security", "CVE", vulnerability fixes |
🔒 |
| Documentation |
"docs:", guides, README, help |
📖 |
Rule: If a commit fits multiple categories, prioritize user impact (features > improvements > fixes).
Step 3: Translate to Customer Language
Translation Framework:
| Technical |
Customer-Friendly |
| "Optimized database queries" |
"Faster loading times" |
| "Refactored auth module" |
"Improved security and reliability" |
| "Added memoization caching" |
"Reduced bandwidth usage by 30%" |
| "Fixed race condition in sync" |
"Resolved sync timing issues" |
| "Updated dependencies" |
"Security and stability improvements" |
| "Added pagination to results" |
"Browse large lists more smoothly" |
Guidelines:
- Focus on user benefit, not technical how
- Use active voice and action verbs
- Mention specific impact (speed, new capability, fixed behavior)
- Avoid jargon (refactor, pipeline, dependency, etc.)
- Start with action: "Create", "Add", "Fix", "Improve", "Support"
Step 4: Structure the Changelog
Format:
# Version [X.Y.Z] - [Release Date]
## ✨ New Features
- **Feature Name**: Brief description of what users can now do.
Context or benefit.
## 🔧 Improvements
- **Feature/Area**: Specific improvement made. Impact or reason.
## 🐛 Bug Fixes
- Fixed issue where [behavior] now [correct behavior]
- Resolved [problem area] that affected [users/use case]
## ⚠️ Breaking Changes (if applicable)
- **Change Name**: What changed and how users need to update.
## 📖 Documentation
- Added/updated guides for [area]
Requirements:
- Group related commits together
- Use headers and icons for scannability
- Include 1-2 sentence descriptions (not bullet points for multi-part features)
- Highlight user impact or benefit
- Keep tone positive, celebratory for new features
Step 5: Apply Brand Voice
Tone Examples:
- Professional/Enterprise: "Advanced authentication options are now available"
- Friendly/Consumer: "You can now invite team members to your workspace!"
- Technical-but-Clear: "Improved JSON parsing performance by 2x"
Check:
- Does it sound like your product talking?
- Would customers understand without developer context?
- Does it emphasize customer benefit?
Quality Checklist
Before finalizing:
- ✓ All commits categorized appropriately
- ✓ Customer-friendly language (no jargon)
- ✓ Action verbs and active voice
- ✓ User benefit mentioned or implied
- ✓ Consistent formatting and tone
- ✓ Grouped logically by feature area
- ✓ Breaking changes clearly marked
- ✓ No internal/refactoring commits visible
- ✓ Professional presentation ready to share
Output
Provide:
Structured Changelog
- Clear version/date header
- Categorized sections (Features, Improvements, Fixes, Breaking)
- Customer-friendly descriptions
- Emoji/icons for quick scanning
Release Notes Summary (optional)
- Headline highlighting major feature
- 2-3 key improvements
- Link to full changelog
Editable Markdown
- Ready to paste into CHANGELOG.md
- Save and share immediately
- No manual reformatting needed
- Writing app store update descriptions
- Generating email updates for users
- Creating social media announcement posts
1---2name: changelog-generator3description: Transform technical git commits into polished, user-friendly changelogs and release notes. Automatically categorizes changes, translates developer language into customer-friendly copy, and generates professional changelog entries.4---56# Changelog Generator78## Use This Skill When910- Preparing release notes for a new product version11- Creating weekly or monthly product update summaries12- Documenting changes for customers or stakeholders13- Writing app store changelog submissions14- Generating update notifications for users15- Maintaining public changelog or product update pages16- Creating internal release documentation17- Need to transform commits into customer-facing language1819## When NOT to Use2021- Internal developer documentation (keep technical commit language)22- When commits already have clear user-facing descriptions23- For non-git version control systems24- When detailed technical accuracy is required for developers25- For automated CI/CD commit logs (use raw commits instead)2627## Context: Changelog Maturity2829**Undeveloped**: Raw git commits listed, technical jargon, unclear for customers.3031**Target**: Commits categorized by type, translated to user language, grouped logically, professional formatting.3233**Optimized**: Polished changelog with strategic storytelling, emphasis on customer impact, brand voice, multimedia integration.3435## Core Principle3637Users deserve clear, accessible changelogs that celebrate product improvements. Transform technical commits into customer language that highlights impact, not implementation.3839## Instructions4041### Step 1: Gather Commit History4243**Identify the scope:**4445| Scope Type | Example | Use Case |46|-----------|---------|----------|47| **Date Range** | "March 1–15" | Weekly/monthly updates |48| **Version Range** | "v2.4.0 to v2.5.0" | Release-specific |49| **Time Period** | "Last 7 days" | Recent changes |50| **Branch** | "main since last release" | Staged features |5152**Command pattern** (provide to user):53```54Get all commits from [DATE] to [DATE]55or56Get all commits between version [V1] and [V2]57or58Get all commits from the past [N] days59```6061### Step 2: Categorize Changes6263**Standard Categories:**6465| Category | Indicators | Icon |66|----------|-----------|------|67| **Features** | "feat:", new functionality, user-facing | ✨ |68| **Improvements** | "perf:", "improve", speed, UX enhancements | 🔧 |69| **Bug Fixes** | "fix:", "resolved", issues, errors | 🐛 |70| **Breaking Changes** | "BREAKING", incompatible changes | ⚠️ |71| **Security** | "security", "CVE", vulnerability fixes | 🔒 |72| **Documentation** | "docs:", guides, README, help | 📖 |7374**Rule**: If a commit fits multiple categories, prioritize user impact (features > improvements > fixes).7576### Step 3: Translate to Customer Language7778**Translation Framework:**7980| Technical | Customer-Friendly |81|-----------|-----------------|82| "Optimized database queries" | "Faster loading times" |83| "Refactored auth module" | "Improved security and reliability" |84| "Added memoization caching" | "Reduced bandwidth usage by 30%" |85| "Fixed race condition in sync" | "Resolved sync timing issues" |86| "Updated dependencies" | "Security and stability improvements" |87| "Added pagination to results" | "Browse large lists more smoothly" |8889**Guidelines:**90- Focus on user benefit, not technical how91- Use active voice and action verbs92- Mention specific impact (speed, new capability, fixed behavior)93- Avoid jargon (refactor, pipeline, dependency, etc.)94- Start with action: "Create", "Add", "Fix", "Improve", "Support"9596### Step 4: Structure the Changelog9798**Format:**99100```markdown101# Version [X.Y.Z] - [Release Date]102103## ✨ New Features104105- **Feature Name**: Brief description of what users can now do. 106 Context or benefit.107108## 🔧 Improvements 109110- **Feature/Area**: Specific improvement made. Impact or reason.111112## 🐛 Bug Fixes113114- Fixed issue where [behavior] now [correct behavior]115- Resolved [problem area] that affected [users/use case]116117## ⚠️ Breaking Changes (if applicable)118119- **Change Name**: What changed and how users need to update.120121## 📖 Documentation122123- Added/updated guides for [area]124```125126**Requirements:**127- Group related commits together128- Use headers and icons for scannability129- Include 1-2 sentence descriptions (not bullet points for multi-part features)130- Highlight user impact or benefit131- Keep tone positive, celebratory for new features132133### Step 5: Apply Brand Voice134135**Tone Examples:**136137- Professional/Enterprise: "Advanced authentication options are now available"138- Friendly/Consumer: "You can now invite team members to your workspace!"139- Technical-but-Clear: "Improved JSON parsing performance by 2x"140141**Check:**142- Does it sound like your product talking?143- Would customers understand without developer context?144- Does it emphasize customer benefit?145146## Quality Checklist147148Before finalizing:149150- ✓ All commits categorized appropriately151- ✓ Customer-friendly language (no jargon)152- ✓ Action verbs and active voice153- ✓ User benefit mentioned or implied154- ✓ Consistent formatting and tone155- ✓ Grouped logically by feature area156- ✓ Breaking changes clearly marked157- ✓ No internal/refactoring commits visible158- ✓ Professional presentation ready to share159160## Output161162Provide:1631641. **Structured Changelog**165 - Clear version/date header166 - Categorized sections (Features, Improvements, Fixes, Breaking)167 - Customer-friendly descriptions168 - Emoji/icons for quick scanning1691702. **Release Notes Summary** (optional)171 - Headline highlighting major feature172 - 2-3 key improvements173 - Link to full changelog1741753. **Editable Markdown**176 - Ready to paste into CHANGELOG.md177 - Save and share immediately178 - No manual reformatting needed179- Writing app store update descriptions180- Generating email updates for users181- Creating social media announcement posts182