A changelog kept current, one pull request at a time
by AGNTOfficialAgent template
An agent adds an entry for every merged pull request to your changelog under Unreleased, proposes it as a pull request, and rolls it into a version when you cut a release.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
- 2
- 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
Written while the change is fresh
Each entry is written days, not weeks, after the change merged, while the pull request and its discussion still explain it. The week before a release becomes a read-through instead of an archaeology project.
Proposed, never pushed
Updates arrive as a small pull request against the changelog file, so the entries go through the same review as any other change. The agent never commits to your main branch.
A format readers already know
Entries follow Keep a Changelog — Added, Changed, Deprecated, Removed, Fixed, Security — under an Unreleased heading, each line linking its pull request. Released sections are never rewritten.
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
Where the result lands. The team wiki agents can actually keep current. 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 keep the repository’s changelog current, one small pull request at a time.
Find what is missing
Read the changelog file the user named (default CHANGELOG.md on the default branch). Find the pull requests merged since the newest entry under Unreleased, or since the last version heading. Skip the categories the user excluded — dependency bumps, docs-only, anything labelled internal.
Write entries for readers who upgrade
One line per change, under the matching heading: Added, Changed, Deprecated, Removed, Fixed, Security — or the headings the file already uses. Say what changed for someone using the software, not what the engineer did. End each line with a link to its pull request. If a pull request’s purpose is unclear from its title, description and diff, leave it out and list it in your pull request description as "needs an entry from the author".
Match the file
Keep the existing structure, heading style and line format exactly. Do not reformat or reorder anything you did not add.
Propose, never push
Create a branch, update only the changelog file on it, and open a pull request listing what you added and what you skipped. Keep one open changelog pull request at a time: if yours is still open, update that branch rather than opening another.
Cutting a release
Only when the user says a release has been cut: move the Unreleased entries under a heading with the version and date, leave a fresh empty Unreleased section, and propose it the same way. If asked, create a Notion page with that version’s entries for readers outside engineering.
Boundaries
Never commit to the default branch. Never edit entries under an existing version heading. Never edit any file other than the changelog. Never invent an entry that cannot be traced to a merged pull request. Never create tags or releases.
Shown exactly as it ships. The agent inherits whichever model you already use.
The changelog is a promise to people upgrading
Someone deciding whether to move from 3.2 to 3.4 reads the changelog, not your commit history. They want to know what was removed, what behaves differently and what they must do. A changelog assembled in a hurry from git log tends to answer the question of what engineers did, which is the wrong question. Writing each entry from the pull request, at the time it merges, keeps the focus on what changed for the reader.
Small, continuous updates beat one big rewrite
A changelog written in a single sitting before a release is the part of the release most likely to be wrong, because its author is reconstructing weeks of work from memory and a list of titles. Adding entries continuously spreads the effort into pieces small enough to review properly, and means the Unreleased section is always an accurate preview of the next version — useful in itself for anyone asking what is coming.
Released history is immutable
Once a version heading exists, its entries are a record that people and tooling rely on. The agent only ever writes under Unreleased, and only moves those entries beneath a version heading when you tell it a release has been cut. Correcting an old entry is a decision for a person, made in a pull request of its own, never something an automated run does in passing.
Common questions
Does it commit directly to main?
Never. Every change to the changelog arrives as its own pull request from a separate branch, reviewed like any other change.
We do not use Keep a Changelog. Can it follow our format?
Yes. Show it your existing file; it matches the headings and line style already there rather than imposing a new one.
What does the Notion copy add?
A readable page per release for people who never open the repository — support, sales, customers. A new page is created for each version rather than one page being edited in place.