Release Notes by Agent: From Merged PRs to Readable Notes

Release notes are the most predictable writing task in software. The inputs are known (merged pull requests since the last release), the structure is known (what changed, why users should care, what to watch out for), and the audience is known. Yet on most teams they get written at 6 PM on release day by whoever drew the short straw, from memory, in a rush. The result is either a raw dump of commit messages nobody outside the team can parse, or a vague paragraph that undersells a week of real work.

This is exactly the shape of task an autonomous agent handles well: bounded reading, structured drafting, human sign-off before anything ships. This article walks through how AI release notes actually work in practice, using Skopx's Create Agent as the concrete example, including what the agent reads, how it drafts in your voice, and why the publish step should always park for approval instead of firing automatically.

Why release notes are a good first agent

If you are evaluating what AI agents can realistically do, release notes sit near the top of the list for a simple reason: the task is read-heavy and the single write action is easy to gate.

Consider what the job actually involves:

1. List every PR merged into the main branch since the last release tag or the last run.
2. Read each PR's title, description, and linked issues to understand what changed and why.
3. Sort changes into categories: features, improvements, fixes, breaking changes, internal-only work to omit.
4. Rewrite engineer-speak into user-facing language ("Refactor auth middleware to short-circuit on cached session" becomes "Faster sign-in for returning users").
5. Assemble the draft in your established format and voice.
6. Publish to wherever your notes live: a Notion page, a Slack announcement, a GitHub release, an email.

Steps 1 through 5 are pure reading and drafting. Only step 6 changes anything in the outside world. That split matters, because it means an agent can do 90 percent of the work with read-only access, and the one consequential action can require a human click. Compared with use cases like invoice chasing where every send is a customer-facing write, release notes have an unusually favorable read-to-write ratio.

There is also a compounding benefit: because the inputs are your own PRs, the agent's drafts improve as your team's PR hygiene improves. Teams that run a release notes agent for a few weeks tend to start writing better PR descriptions, because they see exactly what the agent could and could not infer from them.

What the agent reads, concretely

An agent is only as good as its inputs, so it is worth being precise about the reading list. A release notes agent built in Skopx typically uses the GitHub toolkit (or GitLab, or whichever forge you use, from the platform's nearly 1,000 integrations) plus optionally Linear or Jira for issue context.

Merged PRs since the last release. The agent queries for pull requests merged into your release branch within the window. On the first run you tell it the window explicitly ("everything since the v2.4 tag"). On subsequent runs it uses memory: Skopx agents persist state between runs, so the agent stores a cursor (the last PR number or merge timestamp it processed) and each new run picks up exactly where the previous one stopped. This is the same delta mechanism described in how agent memory works, and it is why second and later runs are typically cheaper: the agent reads 12 new PRs instead of re-reading 200.

PR bodies, not just titles. Titles alone produce changelogs like "Fix bug in export". The description usually contains the actual story: what was broken, who reported it, what changed. Good instructions tell the agent to read the body and any linked issue before summarizing.

Labels and conventions. If your team labels PRs (feature, fix, breaking, internal), the agent should use them as the primary sorting signal and fall back to inference only when labels are missing. Explicitly instructing this beats letting the model guess.

The previous two or three published notes. This is the underrated one. The best way to get an agent to match your voice is not an abstract style description ("friendly but professional") but concrete exemplars. Point the agent at your last few published release notes, in Notion or wherever they live, and instruct it to match their structure, heading style, sentence length, and level of technical detail.

What the agent deliberately does not read: the diffs themselves, in most setups. Reading full diffs for 40 PRs burns tokens fast and rarely improves user-facing notes, because the PR description is where humans already explained the change. Reserve diff reading for a narrow instruction like "if a PR touches files under /api and the description does not mention API changes, read the diff summary to check for breaking changes."

Building the agent: instructions that actually work

In Skopx you build this agent by describing it in chat at Create Agent. There is no canvas and no code; the chat assembles the agent, and you refine its plain-language instructions afterward. Instructions are editable and versioned, so you can tighten them release after release and roll back if an edit makes drafts worse.

Here is the skeleton of an instruction set that works, written the way you would actually write it:

Every Friday, gather all PRs merged to main since your stored cursor. Skip PRs labeled internal or chore. Group the rest into Features, Improvements, and Fixes. Anything labeled breaking goes in its own section at the top with a migration note. For each entry, write one sentence in plain language describing the user-visible effect, not the implementation. Match the tone and structure of our last three release notes in the Product Updates page in Notion. If a PR description is too thin to summarize confidently, list it in a "Needs a human sentence" section at the bottom of your report instead of guessing. Draft the notes as a new Notion page and prepare a Slack summary for #announcements, but do not publish either without approval. Success criteria: every non-internal merged PR is either in the notes or in the needs-review list; no entry describes implementation details instead of user impact; nothing was published without approval.

Two details in that skeleton do a lot of work. First, the "Needs a human sentence" escape hatch: an honest agent flags what it cannot infer rather than inventing plausible-sounding descriptions, and giving it a designated place to put uncertainty makes that behavior reliable. Second, the success criteria: Skopx evaluates each run's report against the criteria you set, so "no fabricated summaries" is not a hope, it is a check the run report answers. Writing good criteria is a skill of its own, covered in depth in the guide to agent success criteria.

For the trigger, most teams pick a schedule matching their release cadence ("Every Friday at 15:00 UTC"). Teams that ship continuously often prefer a webhook fired by their release pipeline when a tag is cut, so notes are drafted minutes after the release exists. Skopx treats webhook payloads as untrusted data, so a payload can wake the agent but cannot inject instructions into it.

The publish step: why approval is the whole point

Here is the design decision that separates a useful release notes agent from a liability: drafting is autonomous, publishing is not.

In Skopx, each integration the agent uses gets a grant with a tier: run automatically, ask first every time, or let the agent decide when to ask, plus a drafts-only mode. The right configuration for release notes is nearly always:

• GitHub (reads): runs automatically. Listing and reading PRs is harmless and doing it under approval would defeat the purpose. Under Skopx's approval_required tier, reads flow without approval anyway; only write-shaped actions park.
• Notion page creation: asks first every time. Creating the draft page is a write, and you want to see it.
• Slack post to #announcements: asks first every time. This is the action with an audience.

When the agent reaches a gated action, it does not execute and hope. The action parks as a pending approval showing the exact call and its arguments: the full Notion page content, the literal Slack message text, the target channel. You read exactly what would happen. Approving executes exactly that parked call, once. Rejecting executes nothing. Approvals can also expire, which matters for release notes specifically: notes drafted for Friday's release should not fire silently the following Wednesday if nobody looked at them.

This mechanism, described more fully in how human approval works in agent systems, changes the failure math entirely. The worst case for a well-configured release notes agent is not "wrong announcement sent to the whole company." It is "draft was mediocre, human edited it before approving." That is the same worst case as a junior teammate writing the first draft, at a fraction of the coordination cost.

Be candid about the limit here: approval gates protect you from bad publishes, not from bad drafts. If the agent mislabels a breaking change as a minor fix and the reviewer skims, the error ships with a human signature on it. The approval step reduces the review burden from "write the notes" to "verify the notes," but verification still has to actually happen.

Manual review vs. script vs. agent

It helps to see where an agent sits relative to the two ways teams handle release notes today.

Changelog generators are genuinely good if your team enforces conventional commits with discipline, and if your audience is developers who read commit-style entries happily. The agent's advantage appears when the audience is users or customers, because translation from implementation language to impact language is precisely what scripts cannot do and models can. The human's advantage, judgment about what matters, is preserved by the approval gate rather than replaced.

Budgets, runs, and what a report looks like

A release notes agent should be cheap and predictable, and Skopx gives you the controls to keep it that way. Each agent carries budgets: tokens per run, tokens per day, a maximum step count, and a minute cap. A weekly notes agent reading 20 to 40 PRs fits comfortably inside a modest per-run token budget, and the step cap catches pathological loops (an agent stuck re-fetching the same PR list) before they cost anything meaningful. If an agent trips its budgets three times, Skopx auto-pauses it rather than letting it keep failing on a schedule.

Every run produces a full record. The step timeline shows each action with a humanized label ("Listed 23 merged pull requests", "Read PR #482 description") and each step expands to the raw result if you want to audit what the agent actually saw. The run ends with a markdown report rendered as a document: the drafted notes themselves, the needs-review list, the count of PRs processed, and the evaluation against your success criteria. Duration and token count sit on every run, so cost per release is a number you can read, not estimate. Run history is append-only, which for release notes doubles as a lightweight audit trail of what was drafted, when, and what got approved.

Model choice is per agent. Release notes are a writing-quality task, so most teams point this agent at a strong general model (Claude, GPT, or Gemini among the options), either through the $16/seat Team plan's included tokens or their own API key with zero markup.

A realistic first month

A concrete, hypothetical walkthrough of how adoption tends to go. Framed as an example, not a customer story.

Week 1. You describe the agent in chat, connect GitHub and Notion, and run it manually against the last release as a backtest. The draft gets the fixes right, buries the week's headline feature in the middle, and confidently summarizes one thin PR incorrectly. You edit the instructions: "Lead with the most user-visible change" and "never summarize a PR whose description is under two sentences; flag it instead." Testing against a period whose correct output you already know is the safest way to shake out an agent, a pattern covered in the guide to testing agents before trusting them.

Week 2. First scheduled run. The draft parks as two pending approvals, the Notion page and the Slack post. You rewrite two sentences and approve both. Total human time: about six minutes.

Week 3. The agent's memory cursor means it reads only the twelve new PRs. Three land in the needs-review list because their descriptions were thin. You paste the flagged list into the team channel; two engineers update their PR descriptions; the next run picks the changes up cleanly.

Week 4. Review takes four minutes. The interesting change is upstream: the team now writes PR descriptions knowing an agent will read them, which makes the descriptions better for humans too.

What this walkthrough does not claim: that drafts stop needing edits. They do not. The agent's ceiling is a strong first draft plus complete coverage. The floor it eliminates is the blank page and the forgotten PR.

Where this approach breaks down

Candor about limits, because release notes agents fail in specific, predictable ways.

Thin PR descriptions are unrecoverable. If a PR says "fix it" with no body and no linked issue, no model can tell your users what changed. The agent can flag it, which is the correct behavior, but a team with chronically empty PR descriptions will get chronically long needs-review lists. Fix the inputs or accept the flags.

Marketing-grade launch notes are a different job. An agent produces accurate, readable notes in your established format. A launch announcement with positioning, screenshots, and narrative is a creative task where the PR list is maybe 20 percent of the input. Use the agent's draft as raw material for those, not as the deliverable.

Judgment calls about disclosure stay human. Whether to mention a security fix, how to phrase a deprecation, whether a half-shipped feature behind a flag belongs in public notes: these are policy decisions. Encode the recurring ones as instructions ("never mention PRs labeled security without flagging for review") and let the approval gate catch the rest.

Monorepos with multiple audiences need multiple agents or careful sectioning. One PR stream feeding notes for three products means either per-product filtering logic in the instructions or, often cleaner, separate agents with separate cursors. The tradeoffs mirror the general one agent vs. many question.

If your release process is genuinely just "run the script, paste the output," and your audience is fine with that, a deterministic tool is simpler and you should keep it. The agent earns its place when translation, categorization, and voice matter.

FAQ

Can the agent publish release notes without anyone reviewing them?

Only if you configure it that way, and for anything with an audience you should not. The recommended setup grants reads (listing and reading PRs) as automatic and every publish action as ask-first. The publish then parks as a pending approval showing the exact call and arguments, the literal page content or message text. Approving executes exactly that call once; rejecting executes nothing; unattended approvals can expire. Some teams do allow automatic publishing to a private internal channel while keeping customer-facing surfaces gated, which is a reasonable middle ground since the blast radius of a bad internal draft is small.

How does the agent know which PRs it already covered?

Through persistent memory. Skopx agents store state between runs, so after each run the release notes agent records a cursor, the last merge timestamp or PR number it processed. The next run queries only PRs merged after that point. This makes runs after the first both cheaper and duplicate-free. If you need to regenerate notes for an older window, you can tell the agent explicitly in a manual run ("cover everything between the v2.3 and v2.4 tags") without disturbing the stored cursor logic in your instructions.

What happens if the agent misunderstands a change and writes something wrong?

The draft parks for approval, so the error reaches a human before it reaches an audience; that is the layer doing the real safety work. Beyond that, two instruction patterns reduce wrong summaries: telling the agent to flag PRs it cannot summarize confidently instead of guessing, and setting a success criterion like "every entry describes user impact supported by the PR description," which the run report evaluates against. When an error does slip through, the run's step timeline shows exactly which PR text the agent read, so you can tell whether the model misread it or the description itself was misleading, and fix the right thing.

Do I need to write PRs differently for this to work?

Not to start, but better PR descriptions produce noticeably better drafts. The agent works from titles, bodies, linked issues, and labels. Teams with labeling conventions (feature, fix, breaking, internal) get accurate categorization immediately; teams without them get inference, which is decent but not perfect. The practical pattern most teams settle into: keep writing PRs normally, watch what lands in the agent's needs-review list, and let that list drive incremental hygiene. One or two sentences of user-facing context per PR is usually all the agent needs.

Which model should a release notes agent use?

Whichever writes best in your voice, and you can change it per agent without rebuilding anything. Skopx lets you pick per agent among Claude, GPT, Gemini, Kimi, and more, either bringing your own key across 8 providers with zero markup or using the $16/seat Team plan's included tokens. Release notes are a writing task more than a reasoning task, so a strong general model is the right default; there is little benefit to reserving a heavyweight reasoning model for it. A practical approach is to backtest two models against a past release and compare drafts side by side, since the run reports make the comparison concrete.

The takeaway

Release notes are a translation task with a paper trail: known inputs, known format, one gated publish action. That makes them close to ideal for an autonomous agent with human approval. The agent reads every merged PR so nothing gets forgotten, drafts in the voice your last three releases established, flags what it cannot infer instead of inventing it, and parks the publish so a human signs off on anything with an audience. Your team keeps judgment and voice; the blank page and the forgotten PR go away.

If you want to see how this pattern generalizes, start with how to create an AI agent, or browse the integrations your agent could read from at skopx.com/integrations.