Draft release notes from merged PRs
Collect what shipped from GitHub and Linear, write it for customers, get engineering sign-off.
Automated release notes fix a translation problem: the work is 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 with a one-tap accuracy check, 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.
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 one-tap confirmation 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.