Draft release notes from merged PRs
Collect what shipped from GitHub and Linear, write it for customers, get engineering sign-off.
Every release notes template asks the same two questions: what shipped, and why should customers care? The answers are documented in commits and tickets, but customers read neither. This workflow collects what shipped from GitHub, GitLab and Linear, writes it up in customer language, and gets engineering's sign-off on accuracy before anything publishes.
What does this workflow do?
On a weekly schedule, or on demand when you cut a release, the agent gathers the merged PRs and closed issues since last time, filters out the internal noise (refactors, dependency bumps, test fixes), and groups what's left into features, improvements and fixes.
Then it translates. "Fix race condition in sync worker" becomes "Files now sync reliably when edited by two people at once." The agent knows your product's names for things from your docs and past release notes, so features get called what customers call them. The draft goes to the engineers who built each change, who confirm accuracy with a quick reply, and to marketing if a change deserves a bigger announcement.
How does it work?
- It collects the shipped work. Merged PRs from GitHub or GitLab and closed Linear issues since the last release, linked to each other where they reference the same change.
- It filters and groups. Customer-visible changes in, internal chores out. Grouped into new, improved and fixed. The cut list is shown, so nothing disappears silently.
- It writes in customer language. Grounded in your product terminology and past release notes. Technical accuracy stays: the engineer's PR is the source, restated for the reader.
- Engineering approves accuracy. Each entry routes to its author for a quick confirm or correct. Marketing gets a heads-up when something is announcement-worthy.
- It publishes. To your changelog pipeline, a Notion page, and a summary in Slack. Big items can feed the product launch workflow.
A release notes template you can copy
If you write release notes by hand today, this is the structure the workflow produces, and it works on its own: a dated heading with a one-line theme for the release; a New section with one or two sentences per feature, each stating what the reader can now do; an Improved section for changes to existing behavior; a Fixed section with the symptom described the way a user would describe it; and, where relevant, a closing line on what's coming next.
An example entry: "New: Shared workflow runs. Invite a teammate into a running workflow to review or take over a step. Improved: Search now matches across connected tools in one query. Fixed: Files edited by two people at once no longer lose the second edit."
Why involve the authors at all?
Because the PR title is often not the truth of the change. Features get merged behind flags, fixes turn out partial, and only the author knows. A quick reply from the person who wrote the code costs seconds and prevents the embarrassing changelog entry about a feature that isn't live yet.
The workflow's memory makes the voice consistent. It learns your phrasing conventions, which changes your team considers customer-visible, and which product areas each engineer owns, so routing gets sharper every release.
Works with
GitHub, GitLab, Linear, Slack, Notion. Runs weekly on a schedule, or on demand when you cut a release.
Frequently asked questions
How does it know which changes are customer-visible?
It starts with sensible defaults (user-facing labels, product areas, PR descriptions) and learns from your edits. Changes it excludes are listed for review, so misses are correctable and stay corrected.
Can it match our changelog's voice?
Yes. It learns from your published release notes and your product docs. Corrections persist, so the voice converges after a few releases.
What about features behind feature flags?
This is exactly why authors confirm entries. An engineer marks a flagged feature as held, and the entry waits in the next release's draft until the flag flips.
Where can it publish?
A Notion changelog page and a Slack announcement, from one approved draft. For a changelog on your own site, the approved copy is ready to paste into your publishing flow.
Does it work with both GitHub and Linear at once?
Yes. It links PRs and issues that reference the same change, so one shipped feature appears once, with both sources attached.