To write release notes with AI, first confirm which changes reached users, where they are available, and what users need to do differently. Ask for a draft that keeps shipped changes, limited previews, and known issues separate. Then compare each sentence with the release record before publishing.
This guide uses an original fictional release for a project-notes app called Fieldnote. The version, date, changes, and sample announcement are editorial examples, not a real software release or a live AI test.
1. Prepare a release record with availability attached
A completed development task is not automatically a feature that every customer can use. Give the drafting tool a release record instead of a list of impressive-sounding task titles.
Fictional release: Fieldnote web app, version 2.4, released September 8, 2026. The approved record covers the web app only; it does not establish changes to mobile apps.
- R1 — Shipped to all web users: the upload limit increased from 10 MB to 20 MB per file. The number of files allowed per upload did not change.
- R2 — Shipped to all web users: fixed missing accented characters in newly generated CSV exports. Previously downloaded files are not repaired automatically.
- R3 — Shipped to all web users: the Export command moved from the sidebar to Project menu → Export. Export functionality remains available.
- R4 — Limited preview: dark mode is available only to web workspaces already enrolled in the preview. No general release date or new enrollment instructions are approved.
- R5 — Planned: offline editing. Not included in version 2.4; no delivery date is approved.
- R6 — Internal maintenance: export module refactoring with no additional documented user-visible behavior beyond R2. Do not infer a speed improvement.
- K1 — Known issue: CSV exports containing more than 10,000 rows may time out. The approved workaround is to filter the data and export batches of 10,000 rows or fewer.
Keep source IDs in your editing notes so reviewers can trace a statement. For a real release, confirm the record with the people responsible for deployment and support. A merged change, a test result, and a completed rollout answer different questions.
2. Decide what belongs in the announcement
The Keep a Changelog project describes a changelog as a curated, chronological record of notable changes for each version. That distinction is useful here: raw development history still needs selection and explanation for a human reader.
| Record | Public treatment | Reason |
|---|---|---|
| R1–R3 | Main release notes | Available to all web users |
| R4 | Clearly labeled limited preview | Availability is restricted |
| R5 | Exclude from this release announcement | Planned work is not shipped |
| R6 | Omit as a separate customer benefit | No additional user-visible effect is documented |
| K1 | Known issue with workaround | Users need the operating limit |
Excluding R5 from this announcement does not mean the plan was canceled. Keep it in the appropriate internal planning record. Likewise, R6 may matter in an engineering changelog even though it adds no separate customer-facing benefit in this short notice.
3. Ask for a draft and an inclusion audit
Draft release notes from the approved record below. Audience: existing users of the Fieldnote web app. Release: version 2.4, September 8, 2026. Use sections for Changes, Limited preview, and Known issue. Explain changed behavior and any required user action in plain language. Preserve exact limits, units, platform scope, and availability. Do not turn planned work into shipped features or imply mobile support. Do not invent performance gains, rollout dates, enrollment steps, or claims that all bugs are fixed. Keep the known issue and its approved workaround. After the draft, provide a separate audit mapping every published claim to its source ID. List excluded records and why they were excluded. Keep this audit out of the customer-facing text. APPROVED RECORD: [Paste R1–R6 and K1.]
If the input contains a contradiction, stop the affected claim for review. For example, “20 MB per file” and “20 MB total per upload” are different limits. A drafting tool should not choose one just to finish the paragraph.
4. Review a complete release-note example
Fieldnote web app 2.4 — September 8, 2026
Changes
- Upload files up to 20 MB each, increased from 10 MB. The number of files allowed per upload is unchanged.
- Accented characters are now preserved in newly generated CSV exports. Generate a new export if you need a corrected file; previously downloaded files are not updated automatically.
- To export a project, open Project menu → Export. The command has moved from the sidebar; exporting is still available.
Limited preview
Dark mode is available to web workspaces already enrolled in the preview. It is not generally available, and a general release date has not been announced.
Known issue
CSV exports with more than 10,000 rows may time out. Filter the data and export batches of 10,000 rows or fewer.
The example retains three generally available changes, one restricted preview, and one known issue. It does not announce offline editing or describe internal refactoring as a performance upgrade.
5. Check the phrases that change the meaning
“Larger uploads” needs its unit. R1 concerns each file, not the total size of a batch. Avoid “upload twice as many files,” because the allowed file count did not change.
“CSV export fixed” is too broad. R2 addresses accented characters in new exports. K1 still describes a timeout condition. Combining them into “all CSV issues resolved” would contradict the release record.
“Export removed” changes the feature. R3 removes the old location, not the ability to export. Include the new location so users can complete the same task.
“Dark mode is here” hides the audience restriction. Keep preview eligibility in the same paragraph as the feature. Do not add a Settings path or a sign-up link without approved instructions.
“Offline editing coming next month” invents a commitment. R5 contains neither a release date nor inclusion in version 2.4. Leave it out of this notice rather than presenting a prediction as a promise.
6. Verify the announcement against the actual release
Ask a release owner to verify version, date, platform, and availability. Ask someone familiar with the interface to check the Export location. Confirm the support workaround still applies. The fictional example demonstrates editorial checks; it does not verify that any real app has these behaviors.
Before posting, use the workflow for comparing document versions with AI to review changes between the approved draft and the final copy. Pay particular attention to numbers, qualifiers such as “may,” and wording that distinguishes a preview from general availability.
Keep the approved source record and publication version together. If rollout status changes or a factual correction is required, update the affected statement with a clear correction or update date according to your publishing practice. A concise announcement should help users understand the release as it actually exists.