Draft release notes from work that actually shipped
The change was merged, the ticket is green and the feature still isn't live. Give AI release evidence, not a hopeful list of completed-looking tasks.
What you'll make
a short release-note draft for your readers and a separate table linking each claim to its release evidence.
What you'll need
the change records you’re allowed to share, evidence of what is live (a release or deployment record and a check of the behaviour), the intended reader, and ChatGPT, Claude, Gemini or Copilot in your work account. No repository connection is needed. About 20 minutes.
Example result.
What's new
- Returning to stock search now keeps your selected filters.
- An item without a stock location now shows a missing-location message.1. Agree what counts as shipped
Decide who the notes are for and which environment counts. A change in a preview build isn’t available to production users, and a feature released to a pilot group needs that scope stated.
Gather the changes, the release or deployment record and a check that the behaviour works where readers will meet it. For software, a commit, a merged change, a tagged release and a live deployment are four different records. Keep reverted, disabled, preview-only and unfinished work in a separate list. Leave out confidential issue detail and customer information the draft doesn’t need.
Why this works: AI can translate a checked log into plain language. It can’t tell from a green ticket whether anything reached your users.
What you should see: a list of changes, each with a release state and the record that shows it.
2. Ask for notes and an evidence map
Draft release notes for [reader] from the checked records below.
Include only changes established as released to [audience or environment] and not reverted or disabled. Describe the changed behaviour in plain language. Do not invent measured savings, performance improvements, availability, dates or version numbers.
Return two separate sections:
1. The reader-facing release-note draft.
2. An internal verification table linking each claim to its evidence, plus excluded or unresolved changes and the reason.
Do not turn planned work into a roadmap promise or put internal links in the public draft. Do not publish or send anything.
Checked records:
[records and evidence][reader] is who the notes are for. [audience or environment] is where the change must be live, such as “all production users”. [records and evidence] is your list from step 1.
Why this works: the release-state rule decides what’s included, and the separate table lets you trace each sentence to a record without publishing the internal context. Asking for more polished wording changes the prose. It doesn’t change which records get in.
What you should see: a draft with only the released changes, and a table with a reason for every exclusion.
3. Check every published sentence
Compare the draft with the evidence table and open the important records yourself. Does each sentence describe the change accurately? Does its availability match the audience? Has a wording tidy-up become a performance claim?
Then read it as a user. “Updated search-state reducer” may be accurate but means little. “Returning to stock search now keeps your selected filters” is better, if that’s the behaviour you checked.
Why this works: the model’s table can claim evidence that doesn’t say what it thinks. Only the record itself settles it.
What you should see: every sentence matched to a record that shows the change live for the stated audience.
Check the result
- Every change in the draft is live for the stated audience, not just merged or in preview.
- No sentence claims a speed-up, saving or reduced support volume the records don’t measure.
- Scope conditions such as “pilot group only” survive in the reader’s wording.
- Excluded changes don’t reappear in the title, intro or closing line.
The usual failure: a merged or preview-only change slips in because its ticket looks finished, often with an invented benefit attached. Spot it by matching each bullet to a deployment record, not a ticket status.
Remove the claim about [change]. Its record shows it is [preview only / reverted / disabled / unresolved], so it is not established as shipped to the stated audience. Keep the verified changes and their scope. Do not replace the removed claim with a future launch promise. Update the verification table to explain the exclusion.[change] is the item that shouldn’t be there. Choose the status that matches its record.
Worked example: two released changes, three exclusions
Fictional example. An inventory app’s change log on 6 October 2026:
Stock search keeps filters | deployed, verified in production 6 Oct
Consistent export headings | merged, preview only
New status colours | reverted before release
Missing-location message | deployed, verified in production 6 Oct
Tablet layout | still testingThe first draft said:
- Search is now faster and keeps your selected filters.
- Exports now use consistent column headings.
- Items without a location now show a clear message.
- The failure. Export headings are merged but only in preview, so production users don’t have them. “Faster” appears in no record.
- The repair. The correction prompt for export headings (preview only), then a second pass removing “faster”, gave the two-line draft in the example result. The table now lists the headings, colours and tablet layout with their reasons.
- What it doesn’t say. No claims about time saved or fewer support tickets. The records contain no measurement, and the notes are better for knowing it.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Optional training: keep scope conditions in plain language
If a record says “enabled for the pilot group”, the reader’s sentence must say so too. If the behaviour depends on a setting or account type, include the condition the reader needs. Use a stable reference (a change title, ticket or release record) in the internal table, and keep that link when the wording changes, so a tidy summary can’t drop an availability condition.
Optional training: separate a fix from an outcome
You may have checked that a bug is fixed without measuring what it did for the business. State the behaviour. A fixed error message doesn’t prove better conversion or fewer complaints. If someone supplies a measured outcome, check its definition, period and source before using it, and keep the change and the measurement as two separate statements.
Optional training: check the published page, not the upload
Have the product owner review the final copy and availability, then publish through your usual process. Afterwards, open the public page and read it. A draft file, a merged change and a successful upload are different completion states. Check whether a website change is actually live covers how to tell them apart.