What each part of the prompt does
- Five buckets
- Separating internal changes from user-facing ones is the first step most hand-written notes skip. Refactors and dependency bumps matter to the team but only add noise for customers.
- Grouped by area
- Grouping by the part of the product (billing, editor, mobile app) instead of by ticket number lets readers jump straight to what they use, and it merges three commits about one feature into one line.
- Reader-first sentences
- Starting each item with what the reader can now do turns "fix null check in export" into "Exports with empty columns no longer fail". The change is the same; the second version is the one people understand.
- Breaking changes with actions
- Putting breaking changes first, each with the action required and any deadline, protects the readers who would otherwise discover them in production.
Variations to try
Same idea, one thing changed.
In-app what's new <task>Turn the raw changes below into release notes for [AUDIENCE].</task> <changes> [CHANGES] </changes> <context> Product name and version: [VERSION] Tone: [TONE] </context> <steps> 1. Sort every change into: breaking changes, new, improved, fixed, and internal (not shown to users). 2. Merge entries that describe the same change, and group the rest by the part of the product they touch, not by ticket or commit. 3. Rewrite each user-facing item as one sentence that starts with what the reader can now do or what no longer goes wrong. 4. For each breaking change, add what the reader must do and by when, if the changes say so. 5. If an entry is too vague to explain, list it under questions for me instead of guessing. </steps> <format> At most five short items for an in-app "What's new" panel, the most useful first, each under 15 words. Leave out fixes unless users reported them. End with the questions for me, if any. Do not mention features that are not in the changes. </format>
Internal team notes <task>Turn the raw changes below into release notes for [AUDIENCE].</task> <changes> [CHANGES] </changes> <context> Product name and version: [VERSION] Tone: [TONE] </context> <steps> 1. Sort every change into: breaking changes, new, improved, fixed, and internal (keep these, since this audience is the team). 2. Merge entries that describe the same change, and group the rest by the part of the product they touch, not by ticket or commit. 3. Rewrite each user-facing item as one sentence that starts with what the reader can now do or what no longer goes wrong. 4. For each change, name the area owner if the changes mention one. For each breaking change, add what the reader must do and by when, if the changes say so. 5. If an entry is too vague to explain, list it under questions for me instead of guessing. </steps> <format> A one-sentence headline for the release, then sections in this order: Breaking changes, New, Improved, Fixed. Skip empty sections. End with the questions for me, if any. Do not mention features that are not in the changes. </format>
If the result isn't right
- Paste the full commit messages, not just the first line; the body often holds the user-facing reason.
- Run the prompt once per audience instead of asking for customer and developer notes in one go.
- Keep the questions section; answering it before publishing is cheaper than a correction later.
- Give Claude last release's notes as an example of your house style; it will match the headings and length instead of inventing a format.