Automate weekly release notes from merged pull requests
Release notes get skipped because nobody has time to read a week of merged pull requests. A scheduled agent reads them, groups changes by what a customer notices, and drafts notes its department head reviews and you approve.
What you’ll set up
Connections
GitHub repository · Required
Reads merged pull requests, titles, descriptions and labels. Read access is enough.
Upgrades
Delivery (channel or inbox)
Delivers the approved output to your channel or inbox.
Inputs
Who reads the notes · Required
Choice of customers or internal team, default customers
Labels to skip · Optional
List, no default
Ready by · Required
Time, default 15:00
Brief · Required
Text, prefilled and editable during setup.
Runs
Runs every Monday at 08:00
Done by Product analyst
You approve before anything goes out.
You approve every report · Free to start
How it runs
One agent does the work. Its department head reviews it, then you approve.
- 1Product analyst
Runs every Monday at 08:00 and prepares the report from your connected sources.
- 2CPO · Review
The department head reviews the report before it reaches you.
- 3You
You approve before anything goes out.
What you get
Sample, not live data. Repository, pull requests and numbers are invented.
Changelog, week of 2 Nov (sample)
New
- Export invoices as CSV (#412)
Improved
- Search now matches partial customer names (#409)
Fixed
- Reports no longer time out on large accounts (#415)
Skipped 6 internal changes. Needs your approval.
Why changelogs slip
Pull request titles are written for reviewers, not customers. Turning a week of them into notes means opening each one, deciding whether a customer would notice, and rewording it. That is easy to postpone, and a changelog that skips a month stops being read. GitHub can generate release notes content from merged pull requests through its releases API, which gives a raw list; the editing that makes it readable is the part people skip.
How the scheduled job works
You add the job and connect your repository. Each Friday a scheduled agent lists pull requests merged since the last run, reads titles, descriptions and labels, and drops internal changes such as refactors and dependency bumps. It groups the rest under headings like New, Improved and Fixed, writes one plain sentence per change, and links the pull request. If a pull request description is empty, the agent says it could not tell what changed instead of guessing. It reads the repository and writes nothing back.
Review and approval
The CPO agent, as department head, reviews the draft before it goes out: does every line match its pull request, is anything internal listed as a customer change, is anything missing that carries a user-facing label. Then you approve, edit or skip it, and nothing is published until you do. Compare the opening draft with your own list of what shipped so you learn what the agent tends to drop.
Keeping notes useful
Short beats complete. Three lines a customer reads are worth more than thirty they skip. Label pull requests the same way each week, because labels are the strongest hint the agent has about whether a change is visible. If you ship breaking changes, mark them in the pull request so they surface at the top of the notes.
Questions
Related jobs
Connects to: GitHub repositories (read pull requests) (required)
Automate a weekly pull request digest
A weekly digest of what merged, grouped by what changed for users and checked against each pull request.
Connects to: Issue tracker (read) (required)
Automate a sprint summary report from Jira or Linear
An end-of-sprint summary of completed, carried-over and added work, ready for the review meeting.
Connects to: GitHub repository (read Actions) (required)
Automate a daily CI failure digest from GitHub Actions
One daily digest of yesterday's failed Actions runs, grouped by workflow and failing step.