Agent-written PR and release summaries

Set by agentvia Claude Code (offprint-admin)Rev 12026-10-08

Release notes are a summary of dozens of pull requests, written for people who never read those pull requests. An AI agent that can read the merged PRs and their descriptions is well suited to the first draft: grouping changes, rewriting them in plain language, and flagging anything breaking. The same goes for a summary of one large pull request for reviewers outside the team.

Offprint gives those summaries a stable page your customers, support team, or leadership can read, with a revision history that shows what an agent wrote and what a person edited before it went out.

See example release notes written by an agent for a fictional product.

What you need

An AI agent connected to Offprint. See setup for every client.
Access to the merged pull requests: a coding agent in your repository (Claude Code, Cursor, Windsurf), or a GitHub connector.

1. Release notes from merged pull requests

Write release notes for v2.4 from the PRs merged since the v2.3 tag. Audience: customers and our support team. Lead with one paragraph on what matters most. Then group changes under New, Improved, Fixed, and Breaking changes. Describe each change by what users notice, not by the code. For breaking changes, include before-and-after examples and upgrade steps. Skip internal refactors and dependency bumps.

Some rules that keep agent-written release notes accurate:

Every item should map to a PR. Ask the agent to keep a private list of which PR each line came from, so a person can check it quickly.
Breaking changes go first in the summary, with a link to their section.
No invented numbers. If a PR claims "30% faster", the agent can repeat it; otherwise it shouldn't estimate.

2. Review and publish

Read the draft, fix anything misleading, then:

Publish this to Offprint in the Releases project as "Release notes, v2.4".

The page renders code blocks, headings, and in-page links cleanly. Share the link with support before the release so they can prepare, and with customers when it ships.

3. Summaries of a single large PR

For a big pull request, a reader-friendly summary helps reviewers who aren't in the code every day, like a product manager or a security reviewer:

Summarize this PR for non-engineers: what problem it solves, what changes for users, what the risks are, and how we'll roll it out. Publish it to Offprint and add the link to the PR description.

Add those reviewers as commenters with Share this document in the side panel. They comment on the summary instead of the diff, and the agent can answer their questions in the margin.

4. Keep the notes current

Releases change after the first draft: a feature gets held back, a fix is added late. Update the same document rather than publishing a new one:

Remove gift cards from the v2.4 notes; that change was reverted. Publish the update.

Each update is a new revision at the same link, and the history shows what changed after the first draft.

Tips

One project for all releases, so customers can scroll back through every version.
Write for the reader, not the team. "Discount codes no longer apply twice" beats "Fix double-apply in DiscountService".
Use the permanent short link (offprint.io/d/…) in emails and changelogs; it survives title changes.