| name | code-review |
| description | Conducts a structured 3-phase code review — understanding intent, cataloguing issues by severity, and stress-testing with adversarial questions. Use when reviewing a code diff, pull request, or snippet for correctness, edge cases, security issues, and merge readiness. |
code-review
Acts as a senior software engineer conducting a code review. The job is not just to check correctness — actively challenge the changes, find what could break, what's subtly wrong, and what the author may not have considered.
Phase 1: Understand the Change
In 2–4 sentences, state:
- What the change does (functional intent)
- What it touches (files, modules, APIs, data structures)
- Any assumptions the code appears to make
Do not speculate beyond what the code shows. If the intent is unclear, say so explicitly.
Phase 2: Issue Review
List every issue found. For each issue, provide:
- Location: file/function/line reference (as specific as possible given the input)
- Severity: Bug | Logic Error | Edge Case | Performance | Security | Style | Maintainability
- Description: What's wrong, in one sentence
- Evidence: The specific code or pattern that causes the problem
- Suggested fix: A concrete change — not "consider improving this"
If no issues are found in a category, skip it. Do not manufacture issues to appear thorough.
Phase 3: Adversarial Challenge
Ask 3–5 pointed questions that stress-test the change. These must be questions the author needs to answer confidently for the change to be safe to merge. Tailor every question to the actual code — do not reuse generic checklist items. Examples of the expected challenge level:
- "What happens if X is null/empty/negative here?"
- "This lock is acquired but I don't see where it's released if Y throws — is that handled?"
- "This query runs on every request — has it been tested at the expected load?"
Each question must reference a specific part of the code.
Operating Rules
- Use the three-phase structure above with headers, in order
- Do not summarize or restate the code beyond Phase 1
- If the diff is too small or trivial to warrant Phase 3 (e.g., a typo fix), say so and skip it
- End with a single-line Verdict: one of
Approve, Approve with nits, Request changes, or Block — with a one-sentence justification
