Turn commits into a changelog
Raw commit logs become release notes a user can read, grouped Added / Changed / Fixed, with refactors and dependency bumps dropped.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Grouping into Added/Changed/Fixed and dropping empty headings keeps the changelog scannable, instead of a flat list where the one breaking fix hides under nine chores.
- →Requiring user-facing language rather than commit-speak is what makes a changelog readable by someone who has never seen the codebase's internal names or helper functions.
- →Routing unclear commits to "Needs clarification" instead of silently reclassifying them stops an ambiguous internal message from becoming a confidently wrong user-facing claim.
Part by part
- Added / Changed / Fixed
- Fixed headings rather than free-form grouping, so successive releases are comparable. It is the Keep a Changelog convention, minus the categories most projects never use.
- omit any heading with nothing under it
- Prevents the empty-section padding a model otherwise produces to satisfy the structure it was given.
- what changed for someone using the product, not the internal mechanism
- The translation this prompt exists for. A commit says what the developer did; a changelog entry says what the reader can now do.
- Drop anything a user wouldn't care about
- Explicit permission to discard most of the input. Without it, dependency bumps and CI changes get dutifully rewritten into user-facing prose that means nothing.
- Needs clarification
- A named home for commits too vague to translate honestly, so they surface for a human rather than being invented into plausible features.
Common mistakes
Write a changelog from these commits.Reformats commit messages rather than translating them, so the output is the same internal language with bullet points. Anything a user could act on is still buried under refactor and chore entries.
Summarise these commits for users.Produces a paragraph rather than a list, and a paragraph cannot be scanned or diffed against the previous release. Structure is most of what makes a changelog useful.
Write a changelog and make it sound exciting.Marketing language in a changelog costs trust — readers come to it to find out whether a specific bug was fixed. Enthusiasm makes that harder to determine, not easier.
Questions
Why drop the refactors and dependency bumps?
Because a changelog answers "what changed for me". Internal work belongs in the commit history, which remains available; including it here trains readers that most entries are irrelevant, so they stop reading.
What makes a commit too vague to translate?
Anything that describes a change without its effect — "fix bug", "update logic", "address feedback". The honest response is to flag it, because guessing produces a confident entry describing a feature that may not exist.
Should I still review the output?
Always. The model cannot tell whether a fix was user-visible, whether a change is breaking, or whether two commits describe one feature. Treat it as a first draft that removes the tedious part.
Does this replace conventional commits?
No, and it works far better alongside them. Structured commit messages give the model reliable signal about type and scope; this prompt is most useful precisely where that discipline is missing.