---
name: repo-code-review
description: Review a repository in its current state for bugs, security issues, and guidance-doc (AGENTS.md/CLAUDE.md) compliance. Use when asked to review code, audit the repo/project, or check it before making changes.
---

# Repo Code Review

Provide a rigorous, structured code review of the repository **in its current state**. Follow these steps precisely:

## 1. Eligibility check
Skip (report "No review needed") if any apply: there is nothing meaningful to review (no source files / empty repo), or this exact scope was already reviewed in this session. Otherwise proceed.

## 2. Load guidance docs
Find and read the project's **guidance docs** — root `AGENTS.md`, `CLAUDE.md`, and any in directories the review covers. Use Glob/Grep to locate them (e.g. `**/{AGENTS,CLAUDE}.md`). Treat these as explicit review criteria; cite them when an issue maps to a rule.

## 3. Summarize the repo
Get a concise summary of what the repository is about and its structure, so reviewers share context before diving into code.

## 4. Parallel independent reviews
Launch parallel subagents via the `task` tool (they use whatever model this session was called with; the `explore` agent is read-only). Each subagent reviews one angle and returns a list of issues plus the reason each was flagged (e.g. guidance-doc adherence, bug, historical git context, security):
- **Guidance-doc compliance:** audit the code against AGENTS.md / CLAUDE.md. Guidance docs address the model as it writes code, so not all instructions apply during review.
- **Bug scan:** read only the relevant files; do a shallow scan for obvious bugs and security issues. Focus on large bugs; avoid small issues and nitpicks; ignore likely false positives.
- **Historical context:** read the git blame and history of the relevant code (`git blame`, `git log`) to identify bugs in light of how it evolved.
- **Comments/intent:** read code comments in the relevant files and ensure the code complies with the guidance in those comments.

## 5. Confidence scoring
For each issue found in step 4, launch a parallel subagent that takes the issue description and the guidance docs (from step 2) and scores its confidence on a scale from 0–100, using this rubric verbatim:
- **0** — Not confident at all. False positive that doesn't stand up to light scrutiny, or a pre-existing issue.
- **25** — Somewhat confident. Might be real but unverified; stylistic issues not explicitly called out in the guidance docs don't count here.
- **50** — Moderately confident. Verified as real but possibly a nitpick or rare in practice. Relative to the rest of the repo, it's not very important.
- **75** — Highly confident. Double-checked and very likely to matter in practice; directly impacts functionality, or is explicitly mentioned in the relevant guidance doc.
- **100** — Absolutely certain. Double-checked and confirmed real; happens frequently; evidence directly confirms it.

For issues flagged due to a guidance-doc rule, double-check that the guidance doc actually calls out that issue specifically.

## 6. Filter
Drop any issue scored <80. If none remain at >=80, report no blocking issues.

## 7. Re-check eligibility
Confirm the review is still warranted before writing up.

## 8. Report
Present findings concisely in chat. Cite each bug by file path and line range, with 1–2 lines of surrounding context; when an issue maps to a guidance-doc rule, quote the rule. Format:

```
### Code review

Found N issues:

1. <brief description of issue> (guidance doc path says "<...>")

path/to/file.ext:12-18

2. <brief description of issue> (bug due to <file and code snippet>)

path/to/file.ext:40-45
```

Or, if nothing met the threshold:

```
### Code review

No blocking issues found. Checked for bugs and AGENTS.md/CLAUDE.md compliance.
```

Examples of false positives (for steps 4 and 5):

- Pre-existing issues
- Something that looks like a bug but is not actually a bug
- Pedantic nitpicks that a senior engineer wouldn't call out
- Issues that a linter, typechecker, or compiler would catch (e.g. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself — it is safe to assume they will be run separately as part of CI.
- General code quality issues (e.g. lack of test coverage, general security issues, poor documentation), unless explicitly required in a guidance doc
- Issues that are called out in a guidance doc, but explicitly silenced in the code (e.g. due to a lint ignore comment)
- Changes in functionality that are likely intentional or are directly related to the broader change
- Real issues, but on lines that are outside the review scope

Notes:

- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
- Do not fetch anything from the web (no web search or fetch). Use git commands via Bash for history and context instead.
- You must cite each bug by file path and line range.
- Keep output brief.