From Merged Pull Requests to a Published Changelog
Zero reads the pull requests you merged this week, keeps the user-facing ones, writes the changelog post, and publishes it to your blog, your Resend list, and X in the same run, once you approve the draft.
What Zero delivers: the post, the email, and the thread
This is a real Zero product update, published on vm0.ai on July 20, 2026, shown exactly as it went out: the blog post, the same update as a newsletter, and as a thread on X. One run wrote all three from the week's merged pull requests.
What is changelog automation?
Changelog automation is the practice of generating your product update from the work your team actually merged, instead of writing it from memory at the end of the week. Zero acts as the agent in the middle: it reads merged pull requests in GitHub, keeps the user-facing ones, groups them into themes, writes the changelog post, and publishes it to your blog, a Resend newsletter, and an X thread in a single run. The result is a weekly product update that ships on schedule and says the same thing on every channel.
Why the weekly changelog eats a Friday
Friday afternoon. Thirty-something pull requests merged this week and someone has to turn them into an update people will actually read. You skim the merge list, guess which changes are user-facing, write the post, cut it down for the email, cut it down again for X, then paste each version into a different tool. It is the same reading three times over, and the version that lands on X usually says something slightly different from the one that landed in the inbox.
How Zero turns a week of merges into a published changelog
Step 1: Connect your tools
Step 2: Ask Zero
Step 3: Take it further
GitHub, Resend, X, and Slack integrations for changelog automation
This workflow reads from one tool and writes to three. GitHub is the only source of truth for what shipped; Resend and X are destinations; Slack is where the draft waits for a human. Each connector is granted separately and scoped to what the workflow actually uses, so read access to your repository never implies the right to post from your account.
GitHub integration: what Zero reads to build the changelog
RequiredZero queries the pull requests merged into the repositories you name within your window, and for each one reads the title, the body, the labels, the merge time, the author, and the changed file paths. Those five signals are what separate a user-facing change from an internal refactor: a release-note label is the strongest, the changed paths catch the ones nobody labeled, and the body supplies the detail the title leaves out. In this workflow the GitHub integration is read-only. Zero opens no issues, pushes no commits, and edits no pull requests. Point it at more than one repository and it reads them all in the same pass, so a split frontend and backend still produces a single changelog.
Resend integration: the newsletter Zero sends
RequiredZero reads your Resend audiences so it can address the one you name by name rather than by ID, then creates and sends the campaign: subject line, preheader, HTML body, and plain-text alternative. After the send it reads the result back and reports how many messages were delivered, deferred, and bounced, which is why the report and the campaign never disagree. Send permission is granted separately from audience read access, and Zero never adds, removes, or exports contacts.
X integration: the thread Zero posts
RequiredThe thread is written for X, not truncated from the blog post: one post per theme, an opener that says what changed, and a closing post that links back to the full write-up. Zero posts each entry as a reply to the previous one so the thread holds together, and it checks length before posting rather than letting a post get cut. Write access is scoped to the account you connect, and posting the thread is all it does. Zero does not read your timeline, your mentions, or your direct messages.
Slack integration: where the draft waits for approval
OptionalSlack is optional and it earns its place on the approval step. Zero posts the full draft in the channel you name, including the blog copy, the email subject line, and every post in the thread, and then stops. Nothing publishes until someone replies with approval, and you can ask for a rewrite in the same thread and get an updated draft in place. Skip Slack and the workflow still runs end to end; the draft comes back wherever you started the run instead.
Zero vs. writing it by hand vs. a changelog generator
Changelog automation splits into two problems: deciding what is worth announcing, and getting the announcement to every channel. Most tools solve one of them.
Writing it by hand
Someone reads the merge list, decides what matters, writes the post, and rewrites it twice for email and X. The judgement is good and the copy is on-brand, but it costs the same 90 minutes every week and it is the first thing dropped in a busy week.
A changelog generator
Commit or pull request titles are collected into a release-notes page automatically. It never misses a merge, but it publishes titles rather than themes, cannot tell a refactor from a feature, and stops at one destination.
Zero's changelog workflow
Zero reads the same merges, applies your rule for what counts as user-facing, groups the rest into themes, and writes copy per channel. Blog, Resend, and X publish from one approved draft in a single run, and the run reports what it held back and why.
Tips for better results
Frequently asked questions
How do you automate a changelog from GitHub pull requests?
Connect GitHub to Zero and give it a schedule or a release trigger. Zero reads the pull requests merged in your window, filters them with your rule for what counts as user-facing, groups the survivors into themes, and writes the changelog post. Add Resend and X and the same run publishes it to those channels too.
How does Zero decide which merges are user-facing?
By the rule you give it, applied to four signals: the release-note label, the changed file paths, the pull request title, and the body. A label is the strongest signal and the one most teams standardise on. Anything Zero excludes is listed in the run report with the reason, so a wrong call is visible rather than silent.
Can one draft be published to a newsletter and X at the same time?
Yes. Zero writes the themes once, then adapts them per channel: the blog post in full, the email at inbox length with a subject line and preheader, and a thread with one post per theme. All three publish in the same run from the same approved draft, so the facts cannot drift between channels.
Does anything publish without my approval?
Not unless you ask for it. The default flow posts the draft in a channel and waits. You can approve it, request a rewrite in the same thread, or drop it. If you would rather it publish unattended, say so in the prompt and Zero skips the approval step.
Which tools does the changelog automation need?
GitHub is required as the source of what shipped. Resend and X are required for the two publishing destinations. Slack is optional and is used only for the approval step; without it, the draft comes back wherever you started the run.
What permissions does this workflow need?
GitHub needs read access to the repositories you publish from. Resend needs send permission and audience read access. X needs write access on the account that posts the thread. Slack, if you use it, needs to post in the approval channel. You grant each connector separately in Zero, and revoking one leaves the others untouched.
Can Zero build one changelog from several repositories?
Yes. Name every repository in the prompt and Zero reads them in the same pass, then groups changes by the behaviour they change rather than by which repository they came from. A split frontend and backend still produces one post.
Can I run it on a release tag instead of a weekly schedule?
Yes. Create an automation that starts the workflow when a release is tagged in GitHub. Zero then builds the changelog from the pull requests in that release rather than a date window, and the rest of the run is identical.
Publish this week's changelog
Connect GitHub, Resend, and X, then use the weekly prompt to see the whole run: scan, group, draft, approve, publish.