Platform

Write release notes from merged PRs

Sai reads every pull request merged since your last release, keeps what users will notice, and writes it in plain language. After you approve, it publishes the GitHub release and posts the update where your users and team look.

Get a free API keyBook a demo
Paste into Sai, or send it from your agent
When I push a new release tag, write user-facing release notes from the pull requests merged since the previous tag, and publish them after I approve.

Repository: github.com/acme/app
Range: the previous release tag to the new one (for example v2.13 to v2.14)

For each merged PR:
- Read the title, description, labels, linked issues and screenshots. Open the preview or production app if you need to see the change for yourself.
- Leave out internal changes: refactors, tests, CI, dependency bumps, and anything labeled "internal" or "skip-changelog".
- Write one line a customer would understand: what changed and why it matters to them. No PR jargon or internal names.

Group the notes as Breaking changes, New, Improved and Fixed. Put breaking changes first with the steps to migrate, and link each line to its PR.

Then:
1. Show me the draft and wait for my OK.
2. Publish a GitHub release for the tag with these notes.
3. Add the same notes to the top of our "Changelog" page in Notion.
4. Post a three-line summary with the link in #releases on Slack.

At the end, list the PRs you left out and why.

Watch it run

What Sai does with this prompt

Release notes from pull requests are only useful when someone translates them: PR titles are written for reviewers, not for the people who use your product. Sai reads every merged PR since your last release, keeps what users will notice, writes it in plain language and, after you approve, publishes it to GitHub, your changelog and Slack.

What release notes from pull requests should be

Release notes from pull requests are a short, user-facing summary of what changed in a release, built from the pull requests merged since the previous version. Each line says what is different for the reader and links to the PR for detail; internal work is left out.

Release notes and a changelog overlap but are not the same. A changelog is the running record of every version. Release notes explain one release and point readers to what they should try, update or migrate. Keep a Changelog sums up the principle for both: changelogs are for humans, not machines.

Why release notes from PRs are hard to write

  • PR titles are written for reviewers. "Refactor auth middleware" tells a customer nothing; "Fixed a sign-in loop on Safari" does.
  • The history is noisy. Keep a Changelog warns against dumping commit logs, which are full of merge commits, obscure titles and documentation changes.
  • Automation depends on discipline. GitHub's automatically generated release notes list merged pull requests and contributors, sorted into categories by labels set in .github/release.yml. Tools like release-please build changelogs from Conventional Commit prefixes such as feat: and fix:. Both work only when every PR is labeled or titled consistently.
  • The context is elsewhere. What a change means for users lives in the linked issue, a screenshot or the product itself, not in the diff.
  • Publishing is a second job. The same notes go to the GitHub release, a changelog page, Slack and sometimes a customer email.

A release notes template that works

Group by what the reader cares about, in this order, and skip empty sections:

  1. Breaking changes: what stops working, who is affected and the steps to migrate.
  2. New: features the reader can try now.
  3. Improved: changes to things they already use.
  4. Fixed: bugs they may have hit, described by the symptom.
  5. Deprecated, removed and security: anything going away, and any vulnerability fixes.

Write each line as the outcome for the user, start with a verb, and link the PR or the docs. For example: "Export up to 50,000 rows at once from any report (#914)." Add the version and release date at the top.

Ways to automate release notes, compared

ApproachWorks fromReadable by usersSetupPublishes to
Written by handWhatever the writer remembersYes, if someone has timeNoneWherever the writer pastes it
GitHub generated release notesMerged PR titles and labelsAs good as your PR titlesA .github/release.yml with label categoriesGitHub releases
Conventional Commits tools (e.g. release-please)Commit message prefixesAs good as your commit messagesCommit conventions and a CI actionCHANGELOG file and GitHub releases
SaiPRs, linked issues, screenshots and the app itselfYes, rewritten for customersA plain-English promptGitHub, Notion, Slack, email or a CMS, after your approval

If your team already labels every PR, keep GitHub's generated notes as the raw list and let Sai turn it into the version your users read.

How to write release notes from merged PRs with Sai

  1. Point Sai at the repository. Give it the repo, the tag range and the labels that mean "leave this out". The full prompt is in the Start with a prompt tab above.
  2. Say who the notes are for. Customers, API users or your own team; Sai writes for that reader.
  3. Review the draft. Sai shows the grouped notes and the PRs it left out, with reasons, and waits for your OK.
  4. Approve and publish. Sai publishes the GitHub release, updates your changelog page and posts the summary in Slack.
  5. Make it routine. Run it on every new tag, or every Friday for weekly notes.

Sai ranks #1 on OSWorld, the public benchmark for agents that complete tasks on a real computer, so it can work through GitHub, Notion and a CMS the way a person does, including changelog pages that have no API. Once the routine works, Sai repeats it each release without being watched and only stops for your approval.

From your coding agent or CI: add the Sai MCP server to Claude Code, Codex or Cursor and ask for release notes right after you tag a release, or call POST /v1/agents/message from a release workflow. Read the quick start.

Make your PRs easier to turn into release notes

  • Add a "User-facing change" line to your PR template. One sentence from the author saves a guess later.
  • Label internal work. A skip-changelog label, also listed under exclude in .github/release.yml, keeps refactors and CI changes out of every tool's output.
  • Link the issue. The issue usually explains the user problem better than the diff.
  • Attach a screenshot for UI changes. It helps reviewers now and the release notes later.
  • Mark breaking changes in the title. A ! after the type in Conventional Commits, such as feat!:, or a breaking label.

Related use cases: test your signup flow end to end, turn a document into a slide deck and post one update to every social channel.

Last reviewed October 5, 2026.

Frequently asked questions

How do I write release notes from pull requests?

List the PRs merged since the last release, leave out internal work, and rewrite each remaining change as one line about what is different for the user. Group them as breaking changes, new, improved and fixed, and link each line to its PR. Sai does all of this and waits for your approval before publishing.

What is the difference between release notes and a changelog?

A changelog is the running record of every version. Release notes explain one release for its readers: what to try, what to update and how to migrate. Both should be written for people, not copied from commit logs.

Can GitHub generate release notes automatically?

Yes. GitHub can generate release notes that list merged pull requests, contributors and a link to the full changelog, grouped by labels you set in .github/release.yml. The result reads only as well as your PR titles.

How do I keep internal PRs out of release notes?

Label them, for example with skip-changelog, and exclude that label in .github/release.yml. With Sai, tell it which labels and kinds of change to leave out, and it lists every PR it skipped with the reason.

Do I need Conventional Commits to automate release notes?

Not with Sai. Tools like release-please rely on Conventional Commit prefixes such as feat: and fix:. Sai reads the PR description, linked issues and screenshots instead, so it works with the history you already have.

Can Sai publish release notes to GitHub, Notion and Slack?

Yes. After you approve the draft, Sai publishes the GitHub release, updates your changelog page in Notion or your CMS, and posts a summary in Slack.

Can release notes be written automatically on every new tag?

Yes. Run the task when you push a release tag, from your coding agent, CI or on a schedule. Sai drafts the notes and waits for your approval before publishing.

How should breaking changes appear in release notes?

At the top, before new features, with who is affected and the exact steps to migrate. Link the docs or the PR for details.

Related use cases

DeveloperTest your signup flow end to endRun sign-up, email verification and first login like a new user, on Windows or Mac.Knowledge WorkTurn a document into a slide deckBuild a first-draft deck in PowerPoint or Google Slides from a doc or brief.Personal / ProductivityFind and cancel subscriptions you forgotScan your card statements for recurring charges and walk through each cancellation page.

Ship the notes with the release

Let Sai turn merged PRs into release notes your users read, every time you tag a release.

Get a free API keyBook a demo