Changelog & Release Notes

Produce human-readable changelogs and release notes from git history so users and stakeholders see what changed.

When to Activate

• User asks for "changelog", "release notes", or "what changed in v1.2"
• Preparing a release (before tagging or publishing)
• Maintaining CHANGELOG.md or similar
• After a release cycle to document shipped work

Work Process

1. Get the range — Two refs (e.g. v1.1.0..HEAD, main..release/1.2) or list of commits. Confirm with user if ambiguous.
2. Fetch commits — git log --oneline BASE..HEAD (or equivalent). Optionally filter by path or author per project.
3. Parse and group — If using conventional commits, group by type (feat → Added, fix → Fixed, etc.). Deduplicate and merge similar entries (e.g. "fix login" and "fix auth" → one line or two distinct bullets).
4. Draft entries — One line per change; add issue/ticket ref if project uses them. Do not invent; use commit message or diff to describe. If messages are vague ("fix bug"), infer from diff when possible or use a generic line and note "verify description."
5. Apply project format — Match existing CHANGELOG style (e.g. Keep a Changelog). Omit empty sections. Add version heading and date.
6. Release notes — From the same data: short summary, bullet list of user/developer impact, breaking changes and migration steps, link to full changelog.