Draft release notes from verified changes

Release notes should describe what the reader can actually use. A merged change is not necessarily deployed, and a deployed change may still be limited to a pilot group.

Prepare the input

Provide the verified change list, serving status, intended audience, rollout limits, and known issues. Use plain descriptions of the user impact. Keep speculative roadmap items out of the release facts.

Run the workflow

Ask the assistant to group changes by user outcome and retain any availability conditions. Require a source reference for each claim. Leave missing publication facts as questions for the release owner.

Prompt to copy

Draft release notes from these verified changes: [material].
Audience and rollout: [details]. Known limits: [limits].
Explain user impact and required action in plain language.
Distinguish implemented, deployed, and available-to-this-audience.
Do not invent fixes, dates, metrics, or future commitments.
List unresolved publication facts separately.

Review a worked example

Illustrative change: a new export is deployed for invited testers only. “Export is now available to everyone” is wrong. The note should name the actual audience and any action needed. Check that a known issue has not disappeared during editing.

Check verbs carefully: “added,” “improved,” and “fixed” imply different claims. A mitigation should not be described as a complete fix unless that has been verified. If users must take an action, make it explicit. Keep internal implementation detail only when it helps the reader understand the practical change.

Use it again

Have the release owner confirm the final state immediately before publication. Save the approved facts with the notes. Bot supports preparation; publishing to company systems requires a separate permission and integration scope.