“Bug fixes and improvements” is the release-note equivalent of “we’re excited to announce.” It tells people you shipped, but it teaches them nothing, and the power users who actually read these notes start skipping the column. Good notes name the feature, name the fix, link the docs, and admit what broke. The 12 prompts below force that shape. For longer-form writeups, pair them with release notes drafting.
TL;DR
- Paste your raw engineering changelog or
git loginto one of these prompts and you get user-facing notes grouped into New / Improved / Fixed, with noise (CI, refactors, dependency bumps) stripped out. - Use Prompt 1 for the standard SaaS changelog, Prompt 3 for the App Store / Play Store box (Google Play caps release notes at 500 characters per locale, as of June 2026), and Prompt 5 when something breaks.
- Any current model handles this well. We use Claude Sonnet 4.6 or GPT-5.5 for the bulk rewrites and Claude Opus 4.7 for the breaking-changes and security prompts where a single wrong word causes support tickets.
- The non-negotiables, drawn from the Keep a Changelog standard: describe the user-visible symptom (not the ticket ID), put breaking changes at the top, and keep the structure identical release to release.
Which model to run these on
These prompts are short and the source material is your own changelog, so the model choice is mostly about cost and judgment, not raw capability. As of June 2026:
| Model | Good for | Notes |
|---|---|---|
| Claude Sonnet 4.6 | Default driver for Prompts 1, 2, 7, 8, 11 | Free tier covers light use; bundled in Claude Pro at $20/mo |
| GPT-5.5 | Same bulk work, second opinion on tone | ChatGPT default since ~Apr 2026; Free tier has tight limits |
| Claude Opus 4.7 | Prompts 5 (breaking) and 9 (security) | Worth the extra cost when a misstatement creates tickets or risk |
| Gemini 3.1 Pro | Bulk rewrites, 1M-token context | Useful if you paste a very long multi-release log |
For the prompts themselves, keep the wording short and concrete: paste real source material, name the exact output structure, and list what to skip.
Best for
- Mobile app releases (App Store / Play Store)
- SaaS changelogs and in-app what’s-new panels
- Open-source releases (GitHub Releases page)
- Internal release announcements (Slack / email)
- Major-version migration guides
In every prompt below, replace the [bracketed] placeholders with your own text.
1. Standard 3-section release notes
Below is the engineering changelog for release [version]. Write user-facing release notes in this structure:
- New (3-5 most user-facing additions, named, <=25 words each)
- Improved (3-5 perceptible improvements, not internal refactors)
- Fixed (3-5 named bugs, with the user-visible symptom not the internal ticket)
Skip noise: dependency bumps, CI changes, internal refactors, doc-only edits.
For each item, link to docs if the feature has its own page.
Changelog: [paste]2. Brand-voice release notes
Brand voice: [paste 2-3 sentences of voice description, or one example of an existing post].
Below is the changelog. Write release notes in that voice.
Constraints: each item <=25 words, conversational not corporate, no "we're excited to introduce", no superlatives like "game-changing" or "revolutionary", name specific features and bugs.
Changelog: [paste]3. App Store / Play Store release notes
Write the store "What's New" text for this update.
Hard limit: 500 characters total (Google Play's cap; on the App Store only the first ~100-150 characters show before "more", so front-load the headline).
Produce 4 variants, each leading with a different angle:
- Headline feature
- Bug fix users complained about
- Performance / speed
- Quality-of-life tweaks
For each variant give the under-500-char text plus which user segment it speaks to.
Changelog: [paste]4. Major-release announcement
For major release [N.0], write a 200-word announcement blog post structured as:
- Paragraph 1: what changed at the highest level (1 sentence framing + the single biggest thing)
- Paragraph 2: why this change exists (the user problem it solves)
- Paragraph 3: what migration is needed (link to migration guide if non-trivial)
- Paragraph 4: what's coming next on this track
No marketing superlatives. Honest about scope and tradeoffs.5. Breaking changes section
Below are the breaking changes in release [version] (pasted). Write a "Breaking Changes" section with this structure for each break:
- What broke (the API or behavior that changed)
- Who's affected (which user segment, how to tell if you're affected)
- Migration steps (3-5 concrete commands or code changes)
- Deprecation timeline (when warnings started, when the break shipped, when the old API fully disappears)
- Why we made this change (1 honest sentence)
Breaking changes: [paste]6. Beta program release notes
For the beta release of [feature], write release notes that:
- Clearly signal BETA status in the first line
- Name what to test (specific user flows or features)
- Name known issues you already know about (so users don't report them again)
- Give one concrete way to send feedback (link to issue tracker / form / Discord)
- Set expectations: when this leaves beta, what the next milestone is
<=200 words. Tone: candid, not promotional.7. Tagged release notes for different audiences
Below is the changelog. Generate 2 separate versions for different audiences:
- End-user version: no tech jargon, focus on what they can now do or what stopped breaking
- Developer / admin version: full technical detail, API changes, config keys, deprecations
Same underlying changes, different framing. Cross-reference: the user version links to the dev version for those who want details.
Changelog: [paste]8. Honest release notes when nothing big shipped
This release is mostly small bug fixes and tweaks. No new features.
Write honest release notes that:
- Acknowledge this is a maintenance release (don't oversell)
- Pick the 2-3 fixes that matter most to actual users (not just the most internally complex)
- For each, name the symptom the user was experiencing before
- End with a one-line forward look: what bigger thing is coming next
Changelog: [paste]9. Security-only release notes
This release contains a security fix. Severity: [low / medium / high / critical]. CVE if applicable: [ID].
Write release notes that:
- Lead with the upgrade urgency (without panicking people)
- Describe the issue in user-impact terms (what an attacker could have done) without revealing exploit details before patch adoption is high
- Give the exact upgrade command
- Credit the reporter if applicable
- Link to the CVE / advisory for full technical detail
Security issue: [paste]10. Rollback / hotfix release notes
Release [version] introduced a regression and was rolled back. The hotfix is [hotfix version].
Write release notes that:
- Acknowledge the regression openly (what broke, when, who was affected)
- Explain the hotfix (what changed, why it's safe)
- State the action users need to take (auto-update / manual upgrade / no action)
- Give a one-line "what we're doing so this doesn't happen again"
Honest, not defensive. Users respect candor more than spin.
Regression details: [paste]11. Release notes from a raw commit log
Below is a raw git log between tags [tagA] and [tagB] (pasted).
Classify each commit into: New / Improved / Fixed / Internal (skip) / Breaking.
For each non-skipped commit, rewrite the commit message as a user-facing bullet.
Output:
- Suggested release notes (grouped by category)
- A separate list of commits you classified as Internal so I can sanity-check
- Any commits whose user impact is unclear, flagged for me to clarify
Git log: [paste]12. Audit release notes before publish
Below are draft release notes for [version]. Audit before publish:
- Are all breaking changes called out at the top?
- Are any internal-only changes (CI, refactors) leaking through?
- Is each fix described as a user-visible symptom, not an internal ticket name?
- Are doc links live and pointing to the right anchors?
- Is the tone consistent with prior releases?
For each issue, give a specific rewrite.
Draft: [paste]
Prior release for tone reference: [paste]Common mistakes
- “Bug fixes and improvements” — zero signal; your power users stop reading the column entirely.
- Marketing superlatives (“game-changing”, “revolutionary”) on small changes — the credibility cost compounds across releases.
- Missing a breaking-changes notice, or burying it below “New features” — this guarantees angry tickets. Per the Keep a Changelog standard, put breaks first.
- Naming the internal ticket ID instead of the user-visible symptom — meaningless to anyone outside the team.
- Inconsistent structure across releases (formal one week, jokey the next; sections in a different order) — readers lose the map and it looks unowned.
- Skipping the version-number contract. With Semantic Versioning, a MAJOR bump signals breaking changes, MINOR adds backward-compatible features, and PATCH is fixes only; let your notes match that promise.
FAQ
What’s the actual character limit for app store release notes? As of June 2026, Google Play caps “What’s new” release notes at 500 characters per locale, and Apple’s App Store “What’s New” field allows up to 4,000 characters. The practical limit on iOS is tighter than the technical one: only the first ~100-150 characters show before the “more” link, so lead with the headline. Prompt 3 targets the safe 500-character ceiling that satisfies both stores.
Which changelog categories should I use? The widely adopted Keep a Changelog standard defines six: Added, Changed, Deprecated, Removed, Fixed, and Security. The user-facing New / Improved / Fixed grouping in Prompt 1 is a friendlier subset of that. Pick one scheme and keep it identical every release.
Should I let the AI write the final notes, or just a draft? Treat the output as a draft. The model is good at structure, classification, and tone, but it cannot know which fix your users actually complained about or whether a “minor” API change is secretly breaking for a key customer. Always do a human pass, especially on Prompt 5 (breaking) and Prompt 9 (security).
Can these turn a raw git log into notes directly?
Yes. Prompt 11 takes the output of git log [tagA]..[tagB] and classifies each commit into New / Improved / Fixed / Internal / Breaking, then rewrites the kept commits as user-facing bullets and flags anything ambiguous for you to confirm.
How do I keep tone consistent across releases? Paste a prior release as a reference (Prompt 2 and Prompt 12 both support this). Better still, save a short “voice” snippet and reuse it every time so wording, formatting, and section order stay stable.