Software projects
Write release notes from confirmed changes
Start with changes confirmed in the released version. Explain what users need to know: new behavior, fixes, relevant compatibility or security updates, and any action required. Include limits and affected platforms. Keep internal implementation detail only where it helps readers understand an impact.
A text to start with
Here is the confirmed change list for [product, version]: [list]. The audience is [user type]. Draft release notes for changes that affect them, including behavior, compatibility, relevant security updates and required actions. For each entry, state the impact, affected users, any starting step or limitation, and the supplied reference. Separate internal implementation work and mark anything whose release status is unclear.
Example request. Change the details to fit your situation.Release note entry sheet
Product and version: [ ] Release date, if confirmed: [ ] Source of the confirmed change list: [ ] Change in plain words: [ ] Who is affected (users, plans, platforms): [ ] Where to start using it: [ ] Action users must take, if any: [ ] Limitation or exception: [ ] Reference (issue, ticket or pull request): [ ] Confirmed shipped by: [ ] Internal detail with no relevant user impact: [ ] Items I cannot confirm shipped: [ ]
Shipped changes and user impact
Compare every entry with the confirmed change list. Flag work that was planned or merged but has not reached this release. Keep relevant security, compatibility and required-action changes even when the interface looks the same. Explain their documented impact without inventing consequences. State limits such as affected versions, platforms, plans or settings. Put any action users need to take near the start of its entry. Check names and references against the supplied material, and ask the release owner to resolve uncertainty.
Ask another agent to check the result
Compare these notes with the confirmed release list. Flag unsupported claims and uncertain release status. Look for omitted security, compatibility or required-action items that affect the stated audience. For implementation details, explain whether they help a user understand the documented impact. Do not infer undisclosed fixes or risks.
Confirm and publish
Ask the person who shipped each change to verify its entry, particularly the starting step and limitation. Put the finished notes where users already look for updates, with a link to the fuller change list if you have one. Keep the internal-work list for the team. If a user later reports that a note was wrong, correct it and say what changed.