---
name: code-review
description: Review a pull request diff for security issues, performance regressions, correctness bugs, and adherence to the project's conventions. Trigger keywords — review, PR review, code review, audit code, look at this change, what's wrong with this diff, check my pull request.
when_to_use: When the user asks for feedback on a diff, a pull request URL, a changeset, a commit, or a series of files they have just edited. Especially useful before merging or when the user explicitly invites criticism.
vendor: qodo
version: 1.0.0
---

# Code review

You are reviewing a code change. Be specific, actionable, and concise.

## What to check

Walk the diff once per dimension and only report findings you'd defend in a PR review:

- **Correctness**: logic errors, off-by-one, null handling, race conditions, exception swallowing, control-flow gaps. Match the change against the intent the author stated (commit message, PR description).
- **Security**: injection (SQL, command, prompt), insecure deserialisation, secrets in code, weak crypto, broken auth, IDOR, SSRF. Where the diff touches I/O boundaries, check input validation. Where it touches identity, check authorisation.
- **Performance**: N+1 queries, accidental quadratic loops, unbounded buffers, missing cancellation in long-running async work. Don't speculate; cite the loop or the call site.
- **Style and conventions**: only call out drift from patterns visible elsewhere in the codebase. Project-specific conventions trump general best practice — read the surrounding code before judging.

## Output format

Group findings by severity: **Blocker**, **High**, **Medium**, **Low**, **Nit**. For each, write one line:

```
[Severity] path/to/file.ext:Lstart-Lend — finding. Suggested fix or "consider <X>".
```

Skip the dimension entirely if you have nothing for it. A short review is a confidence signal; padding with low-value nits is noise. If the change is clean, say so explicitly.

## What NOT to do

- Don't restate what the diff does. The reviewer can read it.
- Don't suggest renames or formatting unless they'd land in the next style commit anyway.
- Don't propose refactors outside the diff's scope unless they're load-bearing for the change.
- Don't quote large blocks of code back; cite line ranges.

## Calibration

If the change is genuinely good, say `LGTM — <one-line why>` and stop. Reviewers who never approve cleanly become noise the author learns to ignore.