| name | code-review |
| description | High-precision review of code changes for real bugs, security regressions, and explicit project-guideline violations, with independent verification before reporting. |
| when-to-use | When the user wants feedback on local changes, a branch diff, or a PR before committing or merging. |
| arguments | ["ref"] |
Code Review
Review the requested changes and report only findings you have verified are real. The goal is a short, trustworthy list a senior engineer would stand behind, not an exhaustive dump. A false positive costs more trust than a missed nitpick.
Phase 1: Gather context
git diff for unstaged and git diff --cached for staged changes. If a ref was provided: git diff ${ref}.git status --short to understand whether staged and unstaged changes are mixed.git log --oneline -5 to learn commit and change conventions.- Read root
AGENTS.md/CLAUDE.md (if present) and any such files in directories the diff touches. These encode project-specific rules the review must check against.
If the diff is empty, say so and stop.
Phase 2: Find -- launch review agents in parallel
Launch these as read-only agents concurrently in a single message. Give each the full diff, changed-file list, and relevant guideline files. Each agent returns candidate findings only: file:line, a one-line claim, and why it flagged it. Tell each: report anything with a plausible problem, but skip pure style nitpicks and pre-existing issues on lines this diff did not touch.
Agent 1 -- Correctness (code-reviewer)
Logic errors (inverted conditions, off-by-one, wrong operator); edge cases (nil/empty, boundaries, concurrency); error handling (swallowed errors, missing cleanup on error paths); resource leaks (files, connections, goroutines); race conditions on shared mutable state; API-contract violations (wrong types, ignored return values).
Agent 2 -- Quality & consistency (code-reviewer)
Does the change follow the patterns in the surrounding code? Naming clarity; functions doing too much; inconsistent abstraction level; dead code (unused imports, unreachable branches, commented-out code); duplication that should reuse an existing helper.
Agent 3 -- Security (security)
Input validation at trust boundaries; injection (SQL, command, XSS, template); secrets or PII in logs/responses; auth/authz gaps introduced by the change. Flag with a concrete data-flow story, not a category name. This is a light pass over the diff only. For a full audit with scan and triage artifacts, point the user to /vuln-scan then /triage.
Agent 4 -- Guideline & contract adherence (code-reviewer)
For each rule in the gathered AGENTS.md/CLAUDE.md, check the diff complies. A finding here must quote the specific rule it violates. Skip rules that are guidance for writing code rather than reviewable invariants.
Agent 5 -- Historical and local-context check (code-explorer)
Read git history and nearby comments for the changed files. Flag only issues where history or local comments reveal a concrete contract the diff violates.
Phase 3: Verify -- confirm each candidate before it survives
Collapse duplicates (same file:line + same issue). Then, for each remaining candidate, launch a skeptical code-reviewer verifier in parallel, one per candidate, with this brief:
Your default assumption is that this finding is WRONG. Re-read the cited code yourself; don't trust the summary. Confirm the problem is real, is reachable, and is on a line THIS diff introduced or changed. Reject it if: it's pre-existing, a linter/compiler/type-checker would catch it, it's intended behavior, it's a nitpick a senior engineer wouldn't raise, or a guideline finding doesn't map to an actual rule. End with exactly:
VERDICT: real | false-positive
CONFIDENCE: 0-100
WHY: <one line citing file:line evidence>
Keep only findings with VERDICT: real and CONFIDENCE >= 80. Be willing to drop a plausible-but-unconfirmed finding rather than ship noise.
Phase 4: Report
Organize survivors by file with file:line references. For each:
- Severity: error / warning / suggestion
- What: the issue (and the rule it violates, for guideline findings)
- Fix: the concrete change
End with a one-line verdict: ready to merge, or needs work. If nothing survived verification, say so plainly — "No high-confidence issues found" is a valid and valuable result.
