TL;DR
Paste your git log into Claude or ChatGPT, give it the audience and tone in one line, and ask for three buckets: New features, Improvements, Fixes — each item leading with the benefit, not the implementation. With Claude Opus 4.7 or GPT-5.5 (both default in their apps as of June 2026), a 200-commit sprint becomes a draft your PM edits in about 10 minutes. The hard part is not the writing; it is the review: verify every number, strip anything on the do-not-disclose list, and have the engineer who shipped each change confirm the description. The prompt and checklist below cover both.
Why commit-paste release notes fail
A release note that copy-pastes commit messages is invisible to users. “Fixed null pointer in OrderService” tells a customer nothing, and after two or three of those they stop opening your notes entirely. The structure top teams use solves this by answering three questions per change: what changed, why it matters, and what the user should do.
Lead with user impact, not the feature name. Linear’s changelog rarely runs more than two or three sentences per entry and never opens with an internal feature name — every line states what you can do now that you couldn’t before. The fix is mechanical: instead of “Added batch operations for issues,” write “Move, label, or close multiple issues at once.” AI is well suited to exactly this translation step, because it can read a flat commit list and regroup it around the reader.
When AI fits — and when it doesn’t
AI is the right tool when:
- Your team produces commit messages or a structured changelog each sprint (Conventional Commits —
feat:,fix:,perf:— parse most reliably). - You know who reads your notes (admins, end users, developers) and at what technical level.
- You ship at least monthly and want a repeatable workflow instead of a blank page.
Keep a human owner — usually a PM — on every line before publication, because the model does not know:
- Which features are behind a partial rollout or feature flag and should not be announced to everyone yet.
- Which fixes are sensitive to disclose. Security patches usually need careful, deliberately vague wording so you don’t hand attackers a roadmap to unpatched installs.
- Which improvements touch billed plans, so a free-tier reader doesn’t click through to a paywall.
AI also over-promises by default. “Significantly faster” with no number is filler. If you shipped a real performance win, paste the measured figure (“p95 page load dropped from 1.8s to 0.9s”); if you have no measurement, cut the claim.
What to feed the model
Give it a tight, structured input — quality in, quality out:
- The full
git logor changelog since the last release.git log --oneline v2.3.0..HEADis enough; keep the commit hashes so an engineer can trace any line back. - The audience in one sentence, including technical level.
- Tone (calm, energetic, formal, casual) — one word steers it more than a paragraph.
- The pricing tier or plan each change affects, if relevant.
- A do-not-disclose list: anything security-related, partner-only, or flagged for staged rollout.
Context size is rarely the bottleneck as of June 2026. Claude Opus 4.7 and Sonnet 4.6 carry a 1M-token standard context, Gemini 3.1 Pro is also 1M, and a full sprint of commits is usually a few thousand tokens — so you can paste an entire release without trimming. (On ChatGPT Plus the in-app window is closer to 320 pages; the full 1M only ships on the $200 Pro tier.)
Copy-ready prompt
Convert this engineering changelog into user-facing release notes.
Audience: [audience]
Tone: [tone]
Product: [product_name]
Release version: [version]
Pricing tiers affected (if known): [tiers]
DO NOT publicly mention: [do_not_disclose]
Engineering changelog:
[paste git log here]
Output:
1. Headline (one line): summarize the release in plain language.
2. New features: each item with
- A 4-8 word benefit-led title (what the user can now DO).
- 1-2 sentences describing the user-facing change.
- Plan or tier, if it differs.
3. Improvements: same format, for items that make existing features better.
4. Fixes: terse, one line each. Group user-impacting fixes together;
omit internal-only fixes (refactors, test changes, CI tweaks).
5. Known issues: list any item still open that users might hit.
6. A short "what we're working on next" line, if appropriate.
Rules:
- Lead with the benefit, not the implementation.
- No marketing fluff ("blazingly fast", "next-generation", "game-changing").
- If a claim needs a number to be credible, include the measured one or cut the claim.
- Omit anything in the DO NOT publicly mention list. If unsure, leave it out and flag it.The [bracketed] slots are placeholders — swap in your real values before sending. The “if unsure, flag it” line matters: it turns the model’s uncertainty into a question for you instead of a leaked secret.
The structure that works
| Section | Purpose | Example heading |
|---|---|---|
| Headline | One line a skimmer reads first | ”Faster search and a redesigned billing page” |
| New features | Things users can now do | ”Export any report to CSV” |
| Improvements | Existing features made better | ”Search now ranks recent items first” |
| Fixes | User-impacting bug fixes, one line each | ”Fixed timezone offset on scheduled posts” |
| Known issues | Open items a user might hit | ”Bulk delete is temporarily capped at 500 rows” |
| What’s next | A one-line teaser, when appropriate | ”Coming soon: shared dashboards” |
This is the shape Stripe, Linear, and Figma converge on. It works because it matches how people skim: headline first, scan features, glance at fixes for anything that hit them, then move on.
A pattern worth copying for developer products is Stripe’s two-layer approach: a plain-language, blog-style changelog on the main site for everyone, with each entry linking to a detailed technical changelog in the docs (API version changes, migration steps, code). AI is genuinely useful here, because you generate both layers from one commit list — ask for the human summary first, then for the technical appendix. Figma adds a second axis: every entry is tagged by product area so users can filter to only the updates that touch their workflow.
Review checklist before you publish
The draft is fast; this pass is where the value is. Run all five:
- Read only the feature titles. Does each one say what the user gets, with no internal jargon? If a title needs the body to make sense, rewrite it.
- Verify every number. Percentages, times, quantities — check each against the actual measurement. The model will happily round “1.8s → 0.9s” into “twice as fast” or invent a figure.
- Walk the do-not-disclose list. Confirm nothing leaked: no security specifics, no partner names, no flagged features announced early.
- Spot-check against reality. Have one engineer who shipped a change confirm the description matches what actually went out. Trace any unclear line back to its commit hash.
- Check the timing. Don’t publish notes the same day as a major incident or status-page outage — delay a day if you can, so a “we shipped X” post doesn’t land next to “X is down.”
Common mistakes
- Copy-pasting commit messages verbatim.
- Mixing user-facing and internal changes in one list. Refactors, CI tweaks, and dependency bumps belong in the git history, not the release note.
- Forgetting plan tiers — a lower-plan user sees a feature in the notes, clicks, and bounces off a paywall.
- Padding the list. Five real improvements beat fifteen with filler; users trust a short, honest note more than a long, padded one.
- Letting the model keep an em-dash-heavy, over-formal voice. Match your product’s tone in the prompt.
Closing the loop
Most documentation and changelog platforms (and embedded in-app widgets) report read-through and reactions. Watch which sections users skip — usually a sign the wording drifted too technical — and feed those learnings back into the prompt next sprint. Over a few releases your audience-and-tone line gets sharp enough that the first draft needs almost no editing.
For deeper prompt variations and a full launch-announcement workflow, see the related guides below.
FAQ
How often should we publish release notes? Match your shipping cadence. Weekly works if every note has real substance; monthly is the practical floor. Empty or padded notes train users to stop reading, which is worse than publishing less often.
Which AI model should I use to draft them? Any current frontier model handles this well. As of June 2026, Claude Opus 4.7 and GPT-5.5 are the strongest defaults; Gemini 3.1 Pro is a solid, cheaper option. All three exceed any sprint’s context size, so the choice comes down to which app you already pay for.
Should we include screenshots or GIFs? Yes for new features and visible UI changes — a 15-second GIF explains a layout change faster than two paragraphs. Optional for everything else. AI drafts the words; the visuals are still on you.
Do we list every fix? No. Group the user-impacting fixes and omit internal-only ones (refactors, test changes, dependency bumps). The do-not-disclose list and the “omit internal-only fixes” rule in the prompt handle most of this automatically.
Can AI pull the commits for me too?
Not on its own, but Conventional Commits make the input clean, and tools like git-cliff or a git log one-liner produce a paste-ready list. Feed that to the model and you skip the manual gathering step.
Related
- Prompt library: release notes prompts
- Release notes with AI
- Prompt library: feature launch announcement prompts
Tags: #Workflow #Release notes