Release notes written from what actually merged

At each release, a workflow gathers everything that merged since the last tag, reads the pull requests and tickets behind it, and drafts three versions of the notes: a customer changelog, a support briefing, and an internal engineering summary. A product manager edits and publishes.

01the problem and who owns it

Release notes are written last, by whoever drew the short straw, from memory and a scroll through commit messages like "fix" and "wip". Customer-facing changes get missed, internal refactors get announced as features, and support learns about a changed button from a confused customer.

The product manager owns what gets announced, but the facts live in dozens of pull requests across several repositories. Compiling them is clerical work that crowds out the part only the PM can do: deciding what matters to customers and how to say it.

02what the AI does, step by step

1. Collect the release scopeThe workflow lists every pull request merged between the previous release tag and this one, across each repository in the release, along with linked tickets, labels, and authors.
2. Classify each changeThe model sorts changes into customer-visible features, fixes, performance work, internal refactors, and dependency updates, using labels where they exist and the diff and ticket where they do not. Uncertain items are flagged rather than guessed.
3. Separate what customers can seeOnly customer-visible items move into the public draft. Changes behind a feature flag that is still off are held back and listed separately so nothing unreleased gets announced.
4. Draft for three audiencesCustomers get plain-language benefit statements. Support gets what changed in the interface, known limitations, and likely questions. Engineering gets the full list with links. Each draft follows a template your team approved.
5. Attach evidenceEvery line in each draft links back to the pull request or ticket it came from, so the editor can verify a claim in one click instead of trusting the summary.
6. Route for approval and publishingThe drafts land in a review document or pull request against your changelog. After the PM approves, the workflow publishes to the changelog page, the help center, and the internal channel.

03systems it connects to

• Source control. GitHub or GitLab releases, tags, and merged pull request metadata.
• Issue tracker. Jira or Linear for ticket titles, descriptions, and customer-impact fields.
• Feature flags. A flag service such as LaunchDarkly or an in-house system, to know what is actually turned on.
• Publishing targets. Your changelog page or docs site, a help center such as Zendesk or Intercom, and Slack or Teams.

04human checkpoints

• PM approval of public notes. Nothing customer-facing publishes without the product manager's explicit approval of the final text.
• Flagged item review. Changes the model could not classify confidently go to the author of the pull request for a one-line answer.
• Security fix wording. Notes about security fixes are reviewed by whoever owns disclosure, since a detailed description can help an attacker before customers have upgraded.

05what to measure

• Time from tag to published notes. Measured per release, before and after.
• Editor change volume. How much of each draft the PM rewrites. A falling number means the templates and classification are working.
• Omissions found later. Customer-visible changes that support or customers noticed but the notes missed.
• Support tickets about undocumented changes. Tickets tagged as confusion about a recent change.

06risks and guardrails

• Announcing unreleased work. Reading code without flag state leads to leaks. Treat flag status as an input, and default to holding back anything uncertain.
• Overstated benefits. Models embellish. Keep customer copy literal and tied to the linked evidence, and ban claims about speed or savings unless someone measured them.
• Sensitive details in internal notes. Internal summaries can still circulate. Keep customer names, credentials, and incident details out of the generated text.

07build vs buy

If your team already uses conventional commit messages and labels, changelog tools and the release notes features built into GitHub and GitLab produce a solid technical list for free.

A custom workflow is worth it when releases span several repositories, when flag state decides what is public, or when support and customers need different notes than engineers do.

08related playbooks

Browse every engineering playbook or the full library.