Merged PRs to Launch Copy
Okou 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 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. Okou 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 Okou turns a week of merges into a published changelog
Step 1: Connect your tools
Step 2: Ask Okou
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 Okou reads to build the changelog
RequiredOkou 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. Okou 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 Okou sends
RequiredOkou 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 Okou never adds, removes, or exports contacts.
X integration: the thread Okou 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. Okou 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. Okou 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. Okou 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.
Okou 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.
Okou's changelog workflow
Okou 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 Okou and give it a schedule or a release trigger. Okou 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 Okou 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 Okou 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. Okou 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 Okou 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 Okou, and revoking one leaves the others untouched.
Can Okou build one changelog from several repositories?
Yes. Name every repository in the prompt and Okou 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. Okou 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.