Release notes written from what actually merged
by AGNTOfficialAgent template
An agent reads every pull request merged since your last release and writes the notes your team needs — what changed, what to watch, and what needs a migration.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
- 3
- Tools connected
- ~10 min
- Setup, 4 steps
- Local
- Runs on your machine
- Per category
- You approve
- Any model
- Uses the one you have
What the agent actually does
Every line traces to a pull request
The agent works from the merged pull requests between two releases, not from commit subjects. Each note links the PR it came from, so a reviewer can check any claim in one click and nothing appears in the notes that did not actually ship.
Breaking changes go first, not last
Migrations, removed flags, changed defaults and new required config are pulled to the top and written as instructions. The person upgrading needs those three lines more than the forty that follow them.
Draft for the team, then post
The notes land as a Notion page for review and a short summary in Slack. Nothing is tagged or published on GitHub until somebody with the authority to release says so.
The tools this job needs
GitHub
Where the work arrives. Where the code — and half the process — lives. The agent watches it and reads what turns up in full, rather than matching a rule against a subject line.
Notion
Context the agent pulls in before deciding. The team wiki agents can actually keep current. It is read, not just referenced — which is what lets the decision account for it.
Slack
Where the result lands. Team chat where operations actually surface. Nothing is written here until the agent has formed a view and, where you asked for it, you have approved it.
The brief it works from
This is the actual instruction set the template installs — what the agent is told to do, and what it is told never to do. Every line of it is yours to edit in AGNT after install.
Read the full brief
You write release notes from what actually merged.
Find the range
Start from the release or tag the user names; if none, use the latest release. Compare it with the target branch and collect the pull requests merged in between. Direct pushes with no pull request go in their own list with their commit messages — never drop them silently.
Read pull requests, not commit subjects
For each pull request read the title, description, labels, linked issue and, when the description is thin, the changed files. A commit subject like "fix" or "address review" tells you nothing; the pull request usually does.
Group by consequence
1. Requires action: migrations, removed or renamed options, changed defaults, new required configuration, dropped platform support. Write these as instructions. 2. Users will notice: new capabilities, visible fixes, performance changes they can feel. 3. Internal: refactors, tests, tooling, dependency bumps with no behaviour change. A small diff that changes a default belongs in group 1. A large refactor with no behaviour change belongs in group 3.
Every line links its pull request
No note may describe a change you cannot point at. If a pull request has no description and the diff does not make its purpose clear, list it under "Needs a sentence from the author" with the author’s handle rather than guessing.
Deliver a draft
Create the notes as a Notion page and post a short summary to the Slack channel the user chose: the version, the requires-action items, and a link to the page.
Boundaries
Never create a release, tag or branch on GitHub unless the user explicitly asks in this conversation. Never edit pull requests or issues. Never describe a change as tested, safe or backwards compatible unless the pull request itself says so.
Plain, specific language. "Requests over 10 MB now return 413 instead of timing out" beats "improved large request handling".
Shown exactly as it ships. The agent inherits whichever model you already use.
Commit messages were never written for this
A commit message is written for the next person reading that diff, at the moment of committing — “fix flaky test”, “address review”, “wip”. Release notes are written for someone who never saw the diff and wants to know whether to upgrade. Stitching one into the other is why release notes end up as either a raw git log or a chore somebody does late on a Friday. The pull request is the better unit: it has a title someone thought about, a description, labels and a linked issue, and it maps to one change a reader can understand.
Grouping by impact rather than by type
Conventional groupings — features, fixes, chores — tell a reader what kind of work happened, not what it means for them. The agent sorts by consequence instead: changes that require action, changes users will notice, changes that only matter internally. A dependency bump that alters a default sits in the first group; a large refactor with no behaviour change sits in the last, however many lines it touched.
Gaps are reported, not papered over
Some pull requests arrive with an empty description and a title like “updates”. The agent does not invent a story for those. It reads the diff, writes what it can verify, and lists the pull requests it could not describe confidently so their authors can add a sentence before the notes go out. A note that admits a gap is more useful than one that smooths it over.
Common questions
Does it publish the GitHub release?
Not unless you ask it to. The default is a draft in Notion and a summary in Slack. Creating a release or a tag is a separate, explicit instruction.
What about a monorepo with several packages?
Tell the agent which paths belong to which package. It groups pull requests by the files they changed and writes a section per package, so one team’s release is not buried in another’s.
Does the merge strategy matter?
No. It works from pull requests rather than raw commits, so squash, rebase and merge commits give the same result. Direct pushes with no pull request are listed separately with their commit messages, never silently dropped.