What this prompt does
This prompt converts raw git log output into a polished CHANGELOG.md entry in Keep a Changelog format. It casts the assistant as a senior release engineer and takes three context variables: [version], the [git_log] output, and [audience]. The deliverables are a version heading with today's date in ISO format, commits grouped into Added / Changed / Fixed / Removed / Security, trivial commits (formatting, merge noise, version bumps) dropped, each remaining line rewritten as user-facing present tense, PR or issue numbers linked where present, and a short "Breaking" callout at the top if any change is backward-incompatible.
The structure works because writing a changelog by hand is exactly the step that gets skipped under deadline, leaving an inconsistent or missing history. By categorizing commits into the standard Keep a Changelog sections and dropping noise, the prompt produces a clean, honest record automatically. The [audience] variable matters because end users and integrators need user-facing language, not raw commit messages — telling the model which prefixes are noise (chore, ci, style) lets it strip them instead of listing them.
When to use it
- Tagging a release and needing a clean changelog without the manual grind
- When changelogs keep getting skipped under deadline pressure
- When raw commit messages aren't user-facing enough to publish
- When you want consistent Keep a Changelog formatting across releases
- When a release includes a breaking change that needs a prominent callout
- When you want PR or issue numbers linked automatically from the log
Example output
You get a single Markdown block that pastes directly into an existing CHANGELOG.md: a version heading dated in ISO format, commits sorted under Added / Changed / Fixed / Removed / Security, trivial noise removed, each entry rewritten in user-facing present tense, and PR or issue references linked where the log contained them. If anything is backward-incompatible, a short "Breaking" callout sits at the top. It's formatted to slot into your existing changelog without reformatting. The rewrite step is where the real value lands — raw commit subjects like "fix: null check in parser" become reader-facing lines that explain what changed for the person upgrading, not what the developer typed in a hurry.
Pro tips
- Tell the model which commit prefixes are noise (chore, ci, style) so it strips them instead of listing them
- Set
[audience]to your actual readers so the rewrites land in user-facing language, not developer shorthand - Paste the full
[git_log]for the release range so nothing meaningful is silently dropped - Double-check the "Breaking" callout against your own judgment, since the model infers it from commit messages
- Confirm the version heading date is correct if you're preparing the entry ahead of the actual tag
- Review the grouping; a commit can land in the wrong category if its message was ambiguous
