Code Reviewer
Overview
Review latency is where small pull requests go to wait. Most of what a maintainer catches on a first pass is mechanical — a correctness slip, an unhandled path, a name that misleads — and finding it costs a context switch that the author then waits on. On each push to a pull request, this agent 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.
For: teams who want a consistent first pass on every pull request before a human reads it.
Not for: replacing the human review, or satisfying a branch-protection rule — it never casts a
GitHub approval.
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.
Tools supported
Read access, plus the one review comment it posts. 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.
Scenario examples
This is the one catalog agent you do not prompt, and 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. What a run produces is the review comment. With one Blocking and one Nit finding:No blocking or should-fix findings.
Prerequisites
Catalog ID:
code-reviewer — what the deploy API takes.
This agent is enabled per account. If it is not in your catalog, an account administrator can
request it for your account.
As part of 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.Limitations
- 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”.
- It reviews only what the diff shows. A change that is wrong because of something in a file it did not touch is outside what the review can see — the review is a filter in front of a human, not a replacement for one.
Recommended model
claude-sonnet-5 — the shipped default. The work is judgement over evidence someone else gathered,
where a weaker model produces confident-sounding conclusions that do not hold.
GitHub Agent
Overview
An investigation that ends at “the retry path double-charges” has answered the incident but not the fix. Someone still has to find the code — and a grep against a monorepo returns the string in forty places, ranked by nothing that matters. Give it a characterised problem — an incident, an error message, a failing service. It searches code for the error’s own text, opens every candidate to confirm it rather than trusting the search ranking, and checks what changed there just before the problem started. What comes back is a ranked shortlist of files with the evidence for each, and the durable code change that shortlist points to. For: turning an investigation’s conclusion into the file and the change that explains it. Not for: a vague problem statement, and not for deciding what to do during the incident itself.It runs on concrete evidence. Given a vague problem statement with no error text, no service and no
timeframe, there is nothing distinctive to search for — so pass it the output of an investigation
rather than the original alert.
Tools supported
Read access only. It never writes to a repository.
Scenario examples
In chat, or as a run’s prompt: Locating a failure in codePrerequisites
Catalog ID:
github-file-finder — what the deploy API takes.
This agent is enabled per account. If it is not in your catalog, an account administrator can
request it for your account.
As part of a workflow
It sits downstream of an investigation, not in place of one. A workflow that has localised a failure to a service passes the findings here to turn “this is broken” into “this file is why” — and its shortlist is what a remediation step then acts on. See Orchestrator for how a step delivers work to it.Limitations
- It never modifies a repository. No branch, no commit, no pull request — it reads and recommends. Opening the pull request that applies a fix is Remediation Executor’s job.
- It does not tell you what to do right now. Its recommendation is the durable code change that stops a problem recurring, which is a different question from how to restore service during an incident.
- A vague problem gives it nothing to search for. Without error text, a service or a window, there is no distinctive string to anchor on.
- It sees only what the connection reaches. Repositories outside it are outside the shortlist.
Recommended model
claude-sonnet-5 — the shipped default. The work is judgement over evidence someone else gathered,
where a weaker model produces confident-sounding conclusions that do not hold.
Next steps
Agent catalog
Every deployable agent, and what each one is for.
Integrations list
Connecting GitHub.
Remediation Executor
Turning a recommendation into a pull request.
Approvals
The decision boundary before anything is written.