Guide
How to write release notes with ChatGPT or Claude
ChatGPT or Claude can turn a list of merged changes into release notes customers read, as long as it writes for the people using the product rather than the people who built it. Paste the merged change titles or ticket summaries, and ask for customer notes grouped as New, Improved and Fixed, each line under 20 words, starting with what users can now do and using the product's own screen and button names. Fixes describe the symptom users saw, and anything they can't see (refactors, dependency updates, tests) goes only into a separate internal changelog with ticket IDs. Anything the ticket doesn't make clear is marked for checking, not guessed.
Short answer
- New, Improved, Fixed; nothing users can't see.
- Each line starts with what users can now do.
- Fixes: the symptom, not the cause.
- An internal changelog for the rest, with ticket IDs.
The brief to copy
Release notes brief
"Write release notes for version [number], released [date].
Customer notes: drop anything users can't see (refactors, dependency updates, tests, CI, logging). Sort the rest into New (couldn't do before), Improved (faster, clearer, broader) and Fixed (was broken, now works). One line each, 20 words or fewer, starting with what the user can now do, in our screen and button names. Write fixes as the symptom users noticed. Most-used change first in each group; merge tickets that are one change for the user.
Internal changelog: Keep a Changelog types (Added, Changed, Deprecated, Removed, Fixed, Security), with ticket IDs, an Internal group for invisible work, and a line for support on anything that changes behavior. If a ticket is unclear, put it under Internal with [check: what changed for users?].
Merged changes: [paste]"
A worked example
Illustration: a made-up business. A booking app for salons ships version 4.8 on 10 November with six tickets: BK-311 weekly recurring bookings in the booking form; BK-322 reminder texts sent twice when a booking was edited; BK-325 a front-end framework upgrade; BK-327 a rewritten client search, typical response time from 1.8 to 0.4 seconds; BK-330 more logging on failed payments; BK-333 "tweak onboarding". The notes:
What's new in 4.8
New: Repeat a booking every week from the booking form, until a date you choose.
Improved: Searching on the Clients page is more than four times faster.
Fixed: Clients no longer get the reminder text twice after you edit their booking.
Internal (4.8.0, 2026-11-10): Added: weekly recurring bookings (BK-311). Changed: client search rewritten (BK-327). Fixed: duplicate reminder texts on booking edits (BK-322). Internal: framework upgrade (BK-325), failed-payment logging (BK-330), onboarding change (BK-333) [check: what changed for users?]. For support: a booking edited before today may already have sent two reminders.
The product manager asked about BK-333. It moved one onboarding step, so it gets a line in the next release's notes once the screenshots in the help center are updated.
What stays with the team
- Read each line against its ticket; the AI only knows what the ticket says.
- Use the names on screen, not the code names.
- Leave out fixes for bugs customers never saw.
- Link a help article when a new feature needs setting up.
- Tell support first about anything that changes behavior.
Next step: stop pasting the brief
Releases come every week or two, so keep the brief where the whole team finds it. Stop pasting the same prompt into ChatGPT every time shows where to save it.
Skills for this
- ProductRelease notes from merged changesWrites customer-facing release notes from merged PRs or tickets, grouped New, Improved, Fixed, benefit-first, plus an internal changelog.
- Customer successBug report from a support ticketTurns a customer complaint into an engineering-ready bug report: steps to reproduce, expected vs actual, environment, impact, evidence, and questions to ask.
- ProductUser stories with acceptance criteriaTurns a feature into user stories with Given/When/Then acceptance criteria, edge cases, out-of-scope notes, and an INVEST check per story.
- Operations and adminInternal change announcementWrites an internal email or Slack post for a change: bottom line up front, what changes, why, when, who it affects, what to do, and where to ask.
Questions
Can AI write release notes?
Yes, from the list of what changed. Paste the merged change titles or ticket summaries and ask for customer notes in three groups, New, Improved and Fixed, each line starting with what users can now do, plus a separate internal changelog. Anything it can't tell from the ticket should be marked for you to check, not guessed.
What should release notes include?
Only what users can see: new things they can do, things that got faster or clearer, and bugs they ran into that are now fixed, in the product's own screen and button names. Refactors, dependency updates and tests belong in the internal changelog, which Keep a Changelog groups as Added, Changed, Deprecated, Removed, Fixed and Security, newest version first with its date.
How do you write a bug fix in release notes?
Describe the symptom users noticed, not the cause: "Clients no longer get the reminder text twice after you edit a booking", not "Fixed duplicate SMS job". Don't blame or over-apologize, and skip fixes for bugs that never reached customers.
AI skill
Have your AI write release notes customers read
Put this skill in AI Skill Pod and everyone on your team gets it in their Claude, Cursor or ChatGPT (Pro, Business, Enterprise): one invite link, free to start. Release notes from merged changes has your AI turn merged changes into two sets of notes: customer notes grouped as New, Improved and Fixed, each line under 20 words and starting with what users can do, and an internal changelog in Keep a Changelog's types, with ticket IDs and what support should know.
14 days free · No card needed
Sources
- Keep a Changelog 1.1.0 — changelogs are for humans; the latest version first, with its release date; changes grouped as Added, Changed, Deprecated, Removed, Fixed, Security (read 2026-11-05)
- ProductPlan: Release notes best practices — use plain language and leave the jargon out; keep them short (read 2026-11-05)