# Code Review

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

- Skill: `nateslabach/code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nateslabach/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nateslabach/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: nateslabach (https://skillmd.com/u/nateslabach)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nateslabach/code-review

---


# 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