Changelog Generation

Generate a formatted changelog entry from recent git commits.

Steps

Determine the range:
- Find the last tag: git describe --tags --abbrev=0 2>/dev/null
- If no tags exist, use the last 20 commits
- Ask the user if they want a different range
Collect commits:
- git log <last-tag>..HEAD --oneline --no-merges
- If using conventional commits, parse prefixes (feat:, fix:, docs:, chore:, etc.)
- If not using conventional commits, categorize by analyzing the commit message content
Categorize changes:
- Added — new features (feat:, add, new, introduce)
- Changed — modifications to existing functionality (update, modify, refactor, improve)
- Fixed — bug fixes (fix:, resolve, correct, patch)
- Removed — removed features or deprecated code (remove, delete, drop, deprecate)
- Security — security-related changes (security, vulnerability, CVE)
- Breaking Changes — anything that breaks backward compatibility (BREAKING, breaking:)
Format the entry:
- Use Keep a Changelog format
- Date in ISO format (YYYY-MM-DD)
- Group by category with bullet points
- Include PR/issue references if present in commit messages
Write to CHANGELOG.md:
- If file exists, insert new entry at the top (after the header)
- If file doesn’t exist, create it with the standard header
- Preserve all existing entries — never modify past entries
Show the user for review:
- Display the new entry
- Wait for confirmation before committing

Never modify existing changelog entries — only add new ones at the top.
Preserve the user’s commit style — if they don’t use conventional commits, don’t force it.
Include attribution — if commits reference PRs or contributors, include them.
Ask before committing — the changelog is the user’s release narrative.