Pull request descriptions a reviewer can start from
by AGNTOfficialAgent template
An agent reads the diff, the commits and the linked issue, and writes the description your reviewer needs — what changed, why, how to test it and where to look hardest.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
- 1
- Tool 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
The why, not just the what
The diff already shows what changed. The agent connects it to the linked issue and the commit history to explain why, which is the part a reviewer cannot reconstruct from the code and the part most descriptions skip.
Where to look hardest
It points the reviewer at the files with real logic changes and away from renames, generated files and formatting noise, so twenty minutes of review lands on the three places that deserve it.
Your words stay yours
If the author already wrote a description, the agent adds the missing sections beneath it rather than replacing it. It never touches the title, the reviewers or the target branch.
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.
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 pull request descriptions that let a reviewer start in two minutes instead of twenty.
Gather
Read the pull request, its changed files, its commits and the issue it references ("Fixes #123", "Closes #45"). Read the check runs so you know what CI already verified.
WRITE THESE SECTIONS, OR THE USER’S TEMPLATE IF THEY GAVE ONE - Summary: one or two sentences on what this changes for a user or a caller. - Why: the problem, from the linked issue or the commits. If you cannot find the reason, write "Motivation not stated" — never invent one. - Changes: the meaningful changes grouped by area. Separate logic changes from renames, formatting and generated files, and say so, so the reviewer can skim the noise. - How to test: concrete steps derived from the diff — the endpoint, command, flag or migration involved. State which checks passed in CI and which steps CI does not cover. - Risk and where to look: the files with the subtlest logic, behaviour changes that affect other callers, anything irreversible such as data migrations.
PRESERVE THE AUTHOR’S WORDS If the description already has content, keep it exactly as written and append only the missing sections beneath it under a clear heading. Fill a description in full only when it is empty, or when the author explicitly asks you to rewrite it.
Boundaries
You may update the pull request description and nothing else. Never change the title, base branch, reviewers, labels or draft state. Never approve, request changes, submit a review or merge. Never claim tests pass unless the check runs show them passing. Never describe the change as safe or correct — describe it accurately and let the reviewer judge.
Be concrete and brief. A reviewer should be able to read the whole description in under two minutes.
Shown exactly as it ships. The agent inherits whichever model you already use.
The reviewer starts cold
The author has spent days inside a change and the reviewer has spent none. A good description closes that gap in two minutes: the problem, the approach, the alternatives rejected, and the places where the author is least sure. Without it the reviewer reverse-engineers intent from the diff, which is slow and is exactly where review comments about the wrong thing come from. The agent writes that orientation from material that already exists but that nobody assembled.
Test instructions are the most skipped section
“How to test” is the line most often left as a template placeholder, and it is the one that decides whether a reviewer actually runs the change. The agent derives concrete steps from the diff — the endpoint that changed, the flag that gates it, the migration to run — and states which checks already passed in CI, so manual effort goes where the automation did not reach.
Explaining is not reviewing
This is deliberately not a code reviewer. It does not judge the change or approve it; it describes it accurately so a human can. Keeping the two jobs apart matters: a description that quietly argues the change is correct makes a reviewer less sceptical, not more. The agent flags risk plainly — “this alters the retry timing for every webhook” — and leaves the judgement to the person accountable for it.
Common questions
Will it overwrite a description I already wrote?
No. It appends the sections that are missing beneath your text and leaves your words untouched. Only an empty description is filled in full.
Does it review the code too?
No — that is a separate job, handled by the code review agent. This one explains the change; it does not judge it, approve it or request changes.
What does it say about tests?
Only what the check runs on the pull request show. It never claims tests pass unless CI reports them passing, and it lists the manual steps CI does not cover.