| name | changelog |
| allowed-tools | Bash(git log:*), Bash(git diff:*), Bash(git show:*), Bash(git tag:*) |
| description | Generate an intelligent changelog from recent commits. Use for release notes, version history, or documenting what changed. |
Context
- Current branch: !
git branch --show-current
- Latest tag: !
git describe --tags --abbrev=0 2>/dev/null | head -1
- Recent commits (last 7 days): !
git log --oneline --since="7 days ago" 2>/dev/null | head -20
Arguments
$ARGUMENTS - Optional: time period to look back (e.g., "2 weeks", "since v1.2.0", "last 30 days", "2025-01-01..2025-02-01")
Your task
Generate a well-organized, human-readable changelog from recent git history.
Step 1: Determine the time range
If the user provided a time period in $ARGUMENTS, use it. Otherwise, ask the user what time period they want the changelog to cover. Suggest useful options based on the context above:
- Since a specific tag (if tags exist)
- Last N days/weeks
- A date range
- Since a specific commit
Step 2: Gather commits
Run git log for the chosen time range with full commit messages:
git log --format="%H%n%s%n%b%n---END---" <range>
If there are merge commits, also look at what was merged:
git log --merges --format="%H %s" <range>
If there are very few commits, also inspect the diffs to understand what changed:
git diff --stat <range>
Step 3: Analyze and categorize
Read through all commit messages and diffs. Group changes into categories. Use only categories that have entries — skip empty ones. Choose from:
- Added — new features, commands, tools, or capabilities
- Changed — modifications to existing behavior, UI updates, refactors
- Fixed — bug fixes
- Removed — deleted features, deprecated code removal
- Infrastructure — CI/CD, build system, dependency updates, tooling
- Documentation — README, docs, comments
Step 4: Write the changelog
Write a changelog that is:
- Grouped by category with clear headers
- Concise but meaningful — each entry should explain what and why, not just parrot the commit message
- Deduplicated — combine related commits into a single entry (e.g., a feature + its follow-up fix = one entry)
- Ordered by significance within each category
- Free of noise — omit trivial changes like typo fixes or formatting unless nothing else happened
Format each entry as a bullet point. Include relevant context like file paths or component names only when it helps the reader understand the scope.
Step 5: Present the changelog
Print the changelog in this format:
## Changelog: <description of range>
### Added
- Entry here
### Changed
- Entry here
### Fixed
- Entry here
After presenting, offer to:
- Copy to clipboard (
pbcopy)
- Save to a file
