Generate Changelog
Analyzes git history for a specified time period and generates a vibrant, human-readable changelog that non-technical teams will actually enjoy reading. Perfect for product managers, marketing, support teams, and external release notes.
When to use
Use this skill when the user needs to:
- •Create release notes for stakeholders
- •Summarize development progress for product/marketing teams
- •Generate sprint or iteration summaries
- •Prepare changelog for external communication
Instructions
Step 1: Parse Arguments
The <args> should specify the time period. Supported formats:
- •
last week,last month,last 2 weeks - •
since 2024-01-01,since v1.2.0 - •
from 2024-01-01 to 2024-01-31 - •
v1.0.0..v1.1.0(between tags)
If no period specified, default to "last week" and confirm with the user.
Step 2: Gather Git History
- •Run
git logfor the specified period with full commit messages - •Include merge commits to capture feature branches
- •Gather commit metadata (author, date, files changed)
Example commands:
# Last week git log --since="1 week ago" --pretty=format:"%h|%s|%b|%an|%ad" --date=short # Between dates git log --after="2024-01-01" --before="2024-01-31" --pretty=format:"%h|%s|%b|%an|%ad" --date=short # Between tags git log v1.0.0..v1.1.0 --pretty=format:"%h|%s|%b|%an|%ad" --date=short
Step 3: Analyze and Categorize Changes
Group commits into business-friendly categories:
| Category | Emoji | Keywords to detect |
|---|---|---|
| New Features | 🚀 | feat, add, implement, introduce |
| Improvements | 💪 | improve, enhance, update, optimize |
| Bug Fixes | 🐛 | fix, resolve, repair, correct |
| Security | 🔒 | security, vulnerability, CVE |
| Performance | ⚡ | perf, performance, speed, optimize |
| Breaking Changes | ⚠️ | breaking, BREAKING CHANGE |
| Deprecations | 📦 | deprecate, deprecated |
Transformation rules:
- •Remove technical jargon (PR numbers, file paths, function names)
- •Convert developer language to user-facing benefits
- •Combine related commits into single entries
- •Focus on WHAT changed for users, not HOW it was implemented
Step 4: Generate the Changelog
Create output in this format:
# 📋 Changelog **Period:** [Start Date] → [End Date] --- ## ✨ Highlights > [2-3 sentence summary of the most important changes. Make it sound exciting and valuable!] --- ## 🚀 New Features - **[Feature Name]** — [Brief description of what users can now do] - **[Feature Name]** — [Brief description of what users can now do] ## 💪 Improvements - **[Area]** — [What got better and why it matters] - **[Area]** — [What got better and why it matters] ## 🐛 Bug Fixes - Fixed an issue where [user-facing problem description] - Resolved a problem with [user-facing problem description] ## 🔒 Security - [Description without exposing vulnerability details] ## ⚡ Performance - [Description of what is now faster/more efficient] --- 📊 **Stats:** [X] changes by [Y] contributors 🙏 **Contributors:** @name1, @name2, @name3
Tone Guidelines
Make the changelog feel alive and engaging:
- •Use active voice: "You can now..." instead of "Added ability to..."
- •Celebrate wins: "Finally! Dark mode is here"
- •Be human: "No more frustrating login errors"
- •Add context when helpful: "Based on your feedback, we..."
Step 5: Handle Edge Cases
No commits found:
- •Inform user that no changes were found for the period
- •Suggest alternative time ranges
Too many commits (>100):
- •Warn user about large volume
- •Offer to summarize by category or split into multiple sections
Technical-only changes:
- •If all changes are internal (refactoring, dependencies, CI/CD):
- •Create a brief "Technical Improvements" section
- •Note that no user-facing changes were made
Step 6: Output Options
Ask user their preferred output:
- •Display - Show the changelog in the conversation
- •File - Save to a file (default:
CHANGELOG-[date].md) - •Clipboard - Copy to clipboard for pasting elsewhere
Writing Guidelines
- •
User perspective - Write from the user's point of view
- •❌ "Refactored auth module to use JWT tokens"
- •✅ "Your login is now more secure"
- •
Benefit-focused - Emphasize the benefit, not the implementation
- •❌ "Added Redis caching layer"
- •✅ "Pages load up to 3x faster"
- •
Plain language - Avoid technical terms
- •❌ "Fixed race condition in async handler"
- •✅ "Fixed a rare issue where data could appear incorrect"
- •
Concise - Keep entries to 1-2 sentences max
- •
Positive framing - Frame fixes as improvements
- •❌ "Fixed broken search"
- •✅ "Search now works reliably"
- •
Celebrate big wins - Make important features feel special
- •❌ "Added dark mode"
- •✅ "🌙 Dark mode is finally here! Easy on the eyes, day or night"
- •
Acknowledge feedback - Show users they're heard
- •✅ "You asked, we listened — bulk export is now available"
Arguments
- •
<args>- Time period specification- •Relative:
last week,last 2 weeks,last month - •Since:
since 2024-01-01,since v1.0.0 - •Range:
from 2024-01-01 to 2024-01-31 - •Tags:
v1.0.0..v1.1.0
- •Relative:
Examples:
- •
changelog last week- Changes from the past 7 days - •
changelog since 2024-01-01- All changes since January 1st - •
changelog v2.0.0..v2.1.0- Changes between two releases