code-review git:20260521.91bb666A

Immutable. This exact content never changes and is served at /api/v1/blob/65a22ccbb507ee01.

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