A first pass on every pull request
An agent reviews diffs against your standards — bugs, security, style, missing tests — and leaves structured comments before a human ever looks.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
A first pass on every pull request, in brief
| Tools it needs | GitHub, Jira, Linear, Slack, Sentry |
|---|---|
| Setup | 4 steps, about ten minutes |
| Approval | Yours, per category — nothing is sent on your behalf unless you say so |
| Where it runs | Your own machine. Credentials stay in a local vault. |
What the agent actually does
Reviewers start from an annotated diff
The agent reviews against your written conventions, not a generic style guide — the error-handling pattern your codebase uses, the naming rules, the architectural boundaries you care about. Standards nobody had time to enforce consistently get enforced on every diff.
Security and edge cases first
Unvalidated input, injection paths, unhandled failure modes, race conditions, resources that are never released. It reads for the failure classes that survive human review precisely because they require reading carefully at the end of a long day.
Humans review the review
Comments land on the PR as suggestions, not verdicts. Nothing merges on an agent’s say-so. The value is that the reviewer starts from a diff whose obvious problems are already annotated.
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.
Jira
Context the agent pulls in before deciding. The ticket system of record for engineering work. It is read, not just referenced — which is what lets the decision account for it.
Linear
Context the agent pulls in before deciding. Fast issue tracking that deserves fast automation. 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.
Set it up
- Connect GitHub with one sign-in and choose which repositories are in scope.
- Give the agent your conventions — a contributing guide, a style document, or a skill you write for it.
- Start in comment-only mode on a single repository so the team can judge signal against noise.
- Tune what it comments on, then expand to the repositories where it proved useful.
You can see exactly what it did
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 review pull requests before a human does. Your purpose is not to replace the reviewer — it is to make sure their attention is spent on design rather than on catching a missing null check for the fortieth time.
Read for, in this order
Correctness first: logic errors, off-by-one, unhandled failure modes, race conditions, resources never released, state mutated where it should not be. Then security: unvalidated input, injection paths, secrets in code or logs, authorisation checks that can be bypassed, anything that trusts a caller-controlled value. Then missing tests, specifically for the branch this diff introduces. Then the house conventions the team has actually written down.
Read the four-hundredth line as carefully as the first. Diff fatigue is the reason mechanical defects survive human review, and not being subject to it is most of your value.
Comment like someone who wants to be read
Be specific. Point at the line, say what goes wrong, and say under what conditions. "This will throw when the list is empty, which happens on a first-time user" is actionable. "Consider adding error handling" is noise, and enough noise gets you muted within a week.
Stay quiet about taste
Formatting, naming preference, and how you would have structured it are not your business unless the team wrote the rule down. If you have nothing substantive to say, say the diff looks fine and stop. A review with no comments is a legitimate review.
Hard boundaries
You comment. You never approve, never merge, never push, never touch CI configuration. A human decides.
If the diff is too large to review properly, say so rather than pretending. "This is 2,000 lines across 14 files and would be reviewed better as three PRs" is the most useful comment you can leave on some pull requests.
Shown exactly as it ships. The agent inherits whichever model you already use.
What first-pass review is actually for
The purpose is not to replace the reviewer — it is to make sure the reviewer’s attention is spent on design rather than on catching a missing null check for the fortieth time. When mechanical issues are already flagged, human review shifts to the questions only a human can answer: is this the right abstraction, does it fit where we are going, is the complexity justified.
Why it catches what tired reviewers miss
Review quality degrades with diff size and with the time of day, and everybody knows it. An agent reads the four-hundredth line as carefully as the first and never assumes a section is fine because it looks familiar. That is a genuine complement to human review rather than a cheap substitute for it.
Reviewing the review
An agent reviewer that comments on everything gets muted within a week. The useful configuration is narrow and confident: flag correctness and security issues, flag violations of standards you actually wrote down, and stay quiet about taste. Tuning that threshold against real PRs in the first fortnight is what determines whether the team keeps it.
Common questions
Can it approve or merge pull requests?
Not unless you deliberately grant that, and most teams never do. The default is that it comments and a human decides.
Does our code get sent to a model provider?
Only to the provider you choose. Point AGNT at a local model through Ollama and review happens entirely on your own hardware — which is the usual answer for private codebases.
How is this different from a linter?
A linter checks rules expressible as patterns. An agent reads intent, so it can notice that a function no longer does what its name and callers assume — which is not a pattern anybody can write.