> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Code Review

> The two catalog agents that read code — Code Reviewer on pull requests, and GitHub Agent for locating a problem in a repository.

Two catalog agents work against your repositories: **Code Reviewer**, which reviews pull requests as
they change, and **GitHub Agent**, which finds where a characterised problem lives in the code.
Neither writes to a repository beyond Code Reviewer's own review comment.

## 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:

| Bucket         | What belongs in it                                |
| -------------- | ------------------------------------------------- |
| **Blocking**   | Something that should stop the merge              |
| **Should-fix** | Worth fixing, but not a reason to hold the change |
| **Nit**        | Minor, and explicitly optional                    |

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:

| Worst finding         | Verdict           | The comment reads                     |
| --------------------- | ----------------- | ------------------------------------- |
| A Blocking finding    | Changes requested | **Code Reviewer — Changes requested** |
| A Should-fix finding  | Comment           | **Code Reviewer — Comments**          |
| Only Nits, or nothing | Approve           | **Code Reviewer — Looks good**        |

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.

| Source          | What it uses it for                                                       |
| --------------- | ------------------------------------------------------------------------- |
| Repository code | Searching for the error's strings, and opening candidates to confirm them |
| File contents   | Reading the surrounding implementation before recommending a change       |
| Recent history  | What changed in a candidate file just before the problem appeared         |

Read access only.

<Note>
  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.
</Note>

**Before you deploy** — model access, and a GitHub connection with read access to the repositories
it searches. The connection is required and gates the agent's only path to GitHub: without one it
cannot search at all, and it fails closed and says so rather than returning an empty result.

**Where it stops.** It never modifies a repository — no branch, no commit, no pull request. Opening
the pull request that applies a fix is
[Remediation Executor](/manage-your-agents/build/catalog/remediation-executor)'s job. It also 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.

## Next steps

<CardGroup cols={2}>
  <Card title="Agent catalog" href="/manage-your-agents/build/catalog/overview">
    Every deployable agent, and what each one is for.
  </Card>

  <Card title="Integrations list" href="/manage-your-agents/build/built-in-integrations">
    Connecting GitHub.
  </Card>

  <Card title="Remediation Executor" href="/manage-your-agents/build/catalog/remediation-executor">
    Turning a recommendation into a pull request, with approval.
  </Card>

  <Card title="Approvals" href="/security-and-governance/controls/approvals">
    The decision boundary before anything is written.
  </Card>
</CardGroup>


## Related topics

- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Use specialized agents](/manage-your-agents/build/use-specialized-agents.md)
- [Continuous Improvement](/manage-your-agents/optimize/continuous-improvement.md)
- [Golden Scenarios](/manage-your-agents/optimize/golden-scenarios.md)
- [Production Readiness & Standards](/modules-and-workflows/ops-automation/production-readiness.md)