Generate Changelog - analyzes git history and creates a human-readable changelog for non-technical teams
Install
npx skillscat add ikatsuba/skills/utils-changelog Install via the SkillsCat registry.
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 weekssince 2024-01-01,since v1.2.0from 2024-01-01 to 2024-01-31v1.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=shortStep 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, @name3Tone 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 dayschangelog since 2024-01-01- All changes since January 1stchangelog v2.0.0..v2.1.0- Changes between two releases