Code Reviewer
On each push to a pull request, it reads the diff and reports what a maintainer needs before merging. Findings come back in three buckets, each naming a file, a line, and the concrete consequence rather than a style preference:
It comments once per commit rather than amending one review, so the history of what was flagged and
when stays readable on the pull request itself.
The verdict
The worst finding decides the verdict, and the agent does not choose it — the buckets are what it produces, and the verdict follows:
Finding nothing is a valid and common result. The review says so rather than padding itself to look
thorough.
Where it stops. It never casts a GitHub approval — its verdict is reported in its own comment,
and “Looks good” is a verdict rather than an approving review, so it cannot satisfy a
branch-protection rule that requires one, and it never merges. Posting that comment is the only
thing it writes: no pushes, no branches, no file changes.
GitHub Agent
Give it a characterised problem — an incident, an error message, a failing service — and 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.
Read access only.
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.
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, with approval.
Approvals
The decision boundary before anything is written.