Changelog Generator
Generates user-facing changelogs and release notes from git commit history.
Install
npx skills add ECNU-ICALK/AutoSkill --skill changelog-generator -g -a claude-code -y- Repository
- ECNU-ICALK/AutoSkill609
- Category
- Git and review
- Updated
- 6mo ago
- License
- See repository
- Context cost
- Lightabout 578 tokens
- Runs scripts
- No, instructions only
What it does
Generates user-facing changelogs and release notes from git commit history. Parses conventional commits, categorizes changes into features, fixes, breaking changes, and more, then rewrites technical messages into customer-friendly language. Use when the user asks to generate a changelog, write release notes, summarize recent commits, prepare CHANGELOG.md, or document what changed between versions.
Changelog Generator
Generate structured, user-facing changelogs from git commit history.
Workflow
Step 1, Gather commits
Determine the commit range from the user's request, then fetch commits:
# Between tags/versions
git log v1.2.0..v1.3.0 --oneline --no-merges
# Since a date
git log --since="2024-03-01" --oneline --no-merges
# Since last tag (default when no range given)
git log "$(git describe --tags --abbrev=0)"..HEAD --oneline --no-merges
If there are no tags and no range specified, ask the user for a date or count.
Step 2, Categorize each commit
Apply these rules based on the commit message prefix:
| Prefix / pattern | Category |
|---|---|
feat: feature: | New Features |
fix: bugfix: | Bug Fixes |
perf: | Performance |
BREAKING CHANGE or !: suffix | Breaking Changes |
security: vuln: | Security |
docs: test: ci: chore: refactor: style: build: | Skip (internal) |
For non-conventional messages, infer category from content. Exclude purely internal commits (test infra, CI config, linting, dependency bumps with no user impact).
Step 3, Rewrite for a non-technical audience
Transform each kept commit into a clear, benefit-focused sentence:
- Strip scope tags like
(api):or(auth): - Expand abbreviations and jargon
- Lead with the user-visible outcome, not the implementation
- Use present tense: "Add", "Fix", "Improve"
- One sentence per entry
Example: fix(auth): race condition in token refresh becomes
"Fix an issue where sessions could expire unexpectedly during use."
Step 4, Format the output
# Changelog, vX.Y.Z (YYYY-MM-DD)
## Breaking Changes
- [entry]
## New Features
- [entry]
## Improvements
- [entry]
## Bug Fixes
- [entry]
## Security
- [entry]
Omit any empty section. Order: breaking changes, features, improvements, fixes, security. If the repo already has a CHANGELOG.md or CHANGELOG_STYLE.md, match its existing conventions instead.
