Automate release notes from GitHub pull requests with Claude or Codex

To automate release notes from GitHub, have an agent list the pull requests merged since your last notes, skip internal ones by label, and rewrite the rest for customers: grouped by what users notice, breaking changes first, every line linked to its PR. Run it weekly or on each release, and publish only after you approve the draft.

What does GitHub's built-in release notes feature already do?

Start with what is free. GitHub's automatically generated release notes "include a list of merged pull requests, a list of contributors to the release, and a link to a full changelog." Add a .github/release.yml and you can group PRs into categories by label and exclude labels or authors, such as bots.

What it does not do is translate. "Refactor billing webhook retries" is a fine PR title and a useless line for a customer. The AI step is the rewrite: "Payments that failed because of a network blip now retry on their own." That is the gap every generator in this space is trying to close.

How much time does automating release notes save?

Less than you might hope per week, and more than it looks over a year. Bret Cameron, who automated his team's weekly notes with a script and OpenAI's API, reports "a time savings of 15-20 minutes each week," and adds, "I still check and tweak the notes manually." The lesson carries over to any setup: the draft is fast, and the human pass is where accuracy comes from. Plan for the review, do not plan it away.

How do you set it up yourself with Claude Code or Codex?

1. Label your PRs. At minimum: internal, breaking-change, and one label per user-facing area. The agent's grouping is only as good as your labels.
2. Write the rules. What counts as user-facing, your changelog voice, and the format of each line.
3. Pick a trigger. Claude Code routines can run on a schedule or on a GitHub release event; the Claude GitHub App "must be installed on the repository" for event triggers. Codex scheduled tasks can trigger on pull request activity on eligible plans, on the web and mobile.
4. Decide where the draft waits. A routine runs to completion without pausing, so have it open a pull request against your changelog file and approve it by merging. That works well for engineers and badly for anyone who does not live in GitHub.

How do you start it in Kavela in about 10 minutes?

In Kavela the draft arrives as an approval anyone on the team can read and sign off, not a pull request. The setup you still do:

1. Paste the prompt below into Kav in your Kavela workspace and name your repository.
2. Connect GitHub (and Slack, if you want the notes posted there) when Kav asks.
3. Review the first draft. Kav then sets the weekly routine in the cloud workspace.

Every Friday at 16:00 <your time zone>, write customer-facing release notes from what we merged this week.

Repository: <GitHub owner/repo>, branch <main>.
List every pull request merged since the last notes I approved (for the first run, the last 7 days).
Skip PRs labelled <internal>, <dependencies> or <chore>, and anything opened by bots.
For the rest, write one line per change for customers: what they can now do or what got better, in plain words, no internal names. Group under New, Improved, Fixed. Put anything labelled <breaking-change> first, under Breaking, with what the customer must do.
Link every line to its pull request. If you cannot tell from the title, description or diff what a PR changes for users, do not guess: list it under "Needs a human" at the end.
Voice: short, concrete, no hype words. Match these past notes: <link or paste>.
Send me the draft as an approval. After I approve, add it to the top of <CHANGELOG.md or your changelog page> and post a 3-line summary to <Slack channel>.
Connect GitHub and Slack when you need them.
Run it once now so I can check the first draft, then set it as a weekly routine.

What goes wrong with AI-written release notes?

• Invented impact. "Faster checkout" from a PR that only renamed a variable. The "needs a human" list exists to stop this.
• Unlabelled PRs. Without labels the agent guesses what is internal. Ten minutes of labelling hygiene saves most of the review.
• Duplicate entries. A run that does not know where the last notes stopped repeats them. Anchor on the last approved notes, not on a date.

Release notes are also the best raw material for your LinkedIn posts, and a natural partner to a weekly SEO audit when you ship site changes. If you run several Claude Code agents on the same repo, Claude Code orchestration covers keeping them out of each other's way.

Stuck on setup? Ask in the Kavela Discord.