Generate the release notes for a version from the merged changes
Release notes assembled from what actually merged, rather than remembered on the day.
The ticket
Generate release notes for a version from its merged changes.
Acceptance criteria
- Every user-facing change is listed and linked to its pull request
- Internal changes are separated from user-facing ones
- Breaking changes are called out with migration guidance
- Generation is repeatable rather than hand-assembled
What lands as proof
Notes where every entry links to the change that produced it, so nothing is invented from memory.
Why teams defer it
- Writing them by hand at release time means whoever is releasing does it fastest, not best.
- Deciding what is user-facing needs product judgement, so a purely mechanical list is not enough.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: generate release notes for a version from its merged changes. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means notes cite each change and the pull request behind it, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.