Turn change records into readable release notes

Release notes should explain user-visible changes while retaining important compatibility information. Keep internal implementation trivia out unless it affects the reader.

Set the editorial constraints

Give the writing teammate a clear audience, purpose and approved facts. Include a short voice sample when tone matters, and state what the draft must not promise. Save a draft file for review rather than treating a generated message as published copy. A final human edit should verify names, dates, claims and links against the source material.

Inputs for this workflow: Approved merged-change list and release scope.

Work through the task

1. Group changes by user impact.
2. Separate fixes, additions and breaking changes.

A brief you can adapt

Draft release-notes.md with concise descriptions and source change IDs. Include migration steps only when supplied and mark unresolved release scope.

The filenames above are examples. Replace them with your actual inputs and destination before submitting the task.

Review the deliverable

Confirm every listed change is part of the release and every breaking change has a visible explanation.

Where this approach can fail

A merged change is not necessarily deployed or available to all users.

For the related desktop setup, see company playbook.