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. When the fix is a Kubernetes configuration value kept in git — a resource limit, an image tag, an environment variable, a replica count, a probe, a label or annotation, an HPA or ConfigMap value — it can also open the pull request that changes it. It opens one, on its own branch, with an edit limited to that value, and only after a person approves it. It never merges: nothing reaches the cluster until someone merges the pull request and the change is applied. For: turning an investigation’s conclusion into the file and the change that explains it, and, for a Kubernetes configuration value, into a pull request a person can review. 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
Reading needs read access. Opening a pull request also needs write access to contents and pull
requests on the GitHub connection, and an approval.
Scenario examples
In chat, or as a run’s prompt: Locating a failure in codeOpening a pull request
A workflow or another agent asks for a pull request; a prompt sent straight to this agent does not. The request names the change — the resource, the field, the current value and the new one — and carries the investigation behind it. An orchestrator sends it only when the cause is established, the investigation is confident and cites its evidence, and the agent has located the file that defines the value.1
It checks the request
It opens nothing, and says why, when the change is a Secret, an RBAC object, a resource quota or a
limit range, when it would lower a resource limit, or when the investigation is not confident or
cites no evidence.
2
It prepares the edit
It reads the file from the base branch and replaces exactly the text that holds the current value.
An edit that changes anything but the declared value, or that touches a file defining a Secret or
an RBAC object, is refused.
3
A person approves
The call that opens the pull request is held until a person who can approve it answers in the
Actions inbox, with the edit in front of them. If nobody answers within the agent’s wait — an
hour by default — no pull request is opened.
4
It opens the pull request
On its own branch, against the base branch as it stands when the approval arrives. The description
carries the reason, the runs that support it and the confidence in words. Asking again for the same
change finds the open pull request instead of opening a second one.
Approvals for tool calls are enabled per account. Where they are off, the agent refuses to open a
pull request rather than opening one nobody approved.
Prerequisites
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. An orchestrator asks it for a pull request as the last step, once an investigation has named a Kubernetes configuration value as the cause and the agent has located the file. A pull request is a proposed fix, not an applied one: the workflow reports it beside what to do now, and does not treat the incident as resolved because one was opened. See Orchestrator for how a step delivers work to it.Limitations
- It opens a pull request only for a Kubernetes configuration value, and only after a person approves it. It never merges, never pushes to the base branch, and never opens more than one pull request for a change. Everything else it reads and recommends.
- It never edits a Secret, an RBAC object, a resource quota, a limit range, application code or Terraform, and it never lowers a resource limit. For a fix that is not a Kubernetes configuration value, Remediation Executor can open a pull request against the source.
- A pull request changes the declared value and nothing else. It touches three files at most and changes at most 40 lines, so the person approving reads the whole change.
- 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.