What it does
On each push to a pull request, it reads the diff and reports what a maintainer needs to know before merging. Findings come back in three buckets, and each one names a file, a line, and the concrete consequence rather than a style preference:
It comments once per commit rather than amending a single review, so the history of what was flagged
and when stays readable on the pull request itself.
The verdict
The worst finding in the review decides the verdict, and the agent does not get to choose it — the buckets are what it produces, and the verdict follows from them:
Finding nothing is a valid and common result. The review says so rather than padding itself with
observations to look thorough.
What a review looks like
A comment with one Blocking and one Nit finding:No blocking or should-fix findings.
What it reads
It reviews against its own rubric. There is no policy file to write and no repository convention to
configure — which is the trade: consistent reviews everywhere, rather than reviews tuned per
repository.
Before you deploy
The GitHub connection is required and gates the only path this agent has to GitHub. Without one it
cannot read the pull request at all: it fails closed and returns a verdict saying so, rather than
reviewing blind.
This agent is enabled per workspace. If it is not in your catalog, an account administrator can
request it for your account.
How it is triggered
This is the one catalog agent you do not give a schedule. It is driven by the repositories bound to the review workflow, so a pull request arriving is what starts a run — there is no cron trigger to set in the wizard, and the Triggers step has nothing to collect.Defaults and limits
The time budget degrades rather than fails: past it, the agent reports the findings it already has
rather than abandoning the review.
In a workflow
It is the review step itself rather than a specialist another agent delegates to. A pull request opens or is pushed to, the step runs, and the comment lands on the pull request — the workflow’s output is visible in GitHub rather than only in the console.What it will not do
It never casts a GitHub approval. Its verdict is reported in its own comment — “Looks good” is a verdict, not an approving review — so it cannot satisfy a branch-protection rule that requires one, and it never merges. A maintainer still reviews and merges. Posting that comment is the only thing it writes. It does not push, branch, or change a file.A review the clock stopped never comes back as approve. Where the time budget cut a review short, an
otherwise-empty result is downgraded to Comment and says plainly that it is incomplete — so “no
findings” from a partial review cannot be mistaken for “nothing wrong”.
Next steps
GitHub Agent
The same repositories, read to find the code behind an incident.
Built-in integrations
Create the GitHub connection this agent needs.
Runs & evidence
Read the reasoning behind a finding.
Agent catalog
Every catalog agent, side by side.