code-review git:20260717.120e9bbA

Immutable. This exact content is served forever at /api/v1/blob/7b7e707f26ea5f93.

---
name: code-review
description: >-
  Review changed code for correctness bugs — logic errors, nil/error handling,
  concurrency, resource leaks, edge cases, broken invariants. Reports findings
  first, ordered by severity, then fixes on request. Scoped to correctness, not
  quality or style cleanups. Use when the user says "code review", "review my
  changes", "any bugs", "find bugs", or asks whether a change is correct.
allowed-tools:
  - Bash
  - Read
  - Glob
  - Grep
  - Edit
  - Agent
argument-hint: "[--fix] [focus area]"
---

# Code Review: Correctness

Review the changed code for **correctness bugs** — cases where it does the wrong
thing, crashes, corrupts state, or breaks a contract. This skill is deliberately
scoped to bugs. Do not report reuse, quality, style, or efficiency cleanups here;
those belong to a separate cleanup pass (San's `simplify` skill, where present).

If the arguments include `--fix`, apply fixes after reporting. Otherwise report
only and offer to fix. A leading focus area (e.g. `concurrency`) narrows the
review to that dimension.

## Phase 1: Identify Changes

Run `git diff` (or `git diff HEAD` when changes are staged) to see what changed.
If there are no git changes, review the most recently modified files the user
named or that you edited earlier in this conversation. Read enough of the
surrounding code that each changed line can be judged in context — a line is
rarely a bug on its own, only against the code that calls it and the code it
calls.

## Phase 2: Launch Review Agents in Parallel

Use the Agent tool to launch the dimension agents concurrently in a single
message (foreground — do NOT set `run_in_background`). Pass each agent the full
diff plus the context it needs. Each agent returns a list of findings; every
finding must carry:

- a **severity** — `critical` (crash, data loss, security), `high` (wrong result
  on a realistic input), `medium` (wrong only in an edge case), `low` (fragile,
  latent);
- a **`file:line`** reference;
- a **concrete failure scenario** — specific inputs or interleaving that lead to
  the wrong outcome. A finding with no scenario is a guess; drop it.

### Agent 1: Logic & Control Flow

- Off-by-one, wrong comparison or boolean operator, inverted condition.
- Incorrect boundary handling; loops that skip the first/last item or run one too
  many times.
- Branches that can't be reached, or that fall through when they shouldn't.
- Wrong operator precedence; integer division or truncation where not intended.

### Agent 2: Nil, Errors & Return Values

- Dereferencing a value that can be nil/null/undefined on some path.
- Errors that are swallowed, logged-and-continued when they should stop, or
  returned without wrapping context.
- Ignored return values that carry an error or a "not found" signal.
- Early returns that leave state half-updated.

### Agent 3: Concurrency & State

- Shared state read/written without synchronization; data races.
- Check-then-act races (TOCTOU) on files, maps, or shared fields.
- Deadlocks, lock ordering, holding a lock across a blocking call.
- Goroutine/task leaks; work started but never awaited or cancelled.
- Mutation of a value another reference still assumes is unchanged.

### Agent 4: Resources, Boundaries & Contracts

- Files, connections, handles, subscriptions opened but not closed on every path.
- Use-after-close / use-after-free; double free/close.
- Edge inputs: empty, zero, negative, very large, overflow, unexpected type.
- API misuse: violating a precondition of a function being called, or breaking an
  invariant a caller relies on.

## Phase 3: Verify, Then Report

Aggregate the findings. Before reporting each one, check it against the actual
code once more and discard anything you cannot tie to a concrete failure — false
positives cost the reader more than a missed nitpick. Deduplicate findings that
point at the same root cause.

**Report findings first**, ordered by severity, each as: `file:line` — one-line
statement of the bug — the failure scenario. Keep any summary short and after the
list. If nothing survives verification, say so plainly and name any residual risk
or gap in test coverage.

## Phase 4: Fix (on request)

If `--fix` was passed, or the user asks to fix after seeing the report, apply the
smallest change that removes each confirmed bug — nothing else (no refactors, no
cleanup; that is `simplify`'s job). Re-state what you changed. Where a fix is not
obvious or has trade-offs, present the options and ask rather than guessing.