git:20260521.91bb666 to git:20260929.63848e3

28 added, 21 removed. Audit A to A.

---

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.

+ description: >-

+ Structured 3-phase peer review of a diff or PR — intent, issues by severity,

+ then pointed merge-readiness questions and a verdict. Use for general code

+ review. Not for AI workflow self-fix-and-edit (ai-systems-review) or

+ no-edit devil's-advocate threat models (adversarial-challenge). Phase 3 asks

+ questions only; it is not the adversarial-challenge skill.

---

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

+ Senior peer review of a change. Challenge correctness, find breaks and subtle

+ bugs. Ends with a verdict — does not edit code.

+ **Not this skill:**

+ - Self-review AI workflow code and **apply fixes** → `ai-systems-review`

+ - Devil’s advocate / threat model with **hypotheticals only** → `adversarial-challenge`

+ - Preferred AI sequence: `adversarial-challenge` → decide → `ai-systems-review`

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

+ Do not speculate beyond what the code shows. If intent is unclear, say so.

## Phase 2: Issue Review

- List every issue found. For each issue, provide:

+ For each issue:

- - **Location**: file/function/line reference (as specific as possible given the input)

+ - **Location**: file/function/line

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

+ - **Description**: what’s wrong, one sentence

+ - **Evidence**: the code/pattern that causes it

+ - **Suggested fix**: concrete change — not “consider improving”

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

+ Skip empty categories. Do not manufacture issues.

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

+ ## Phase 3: Merge questions

- Each question must reference a specific part of the code.

+ Ask 3–5 pointed questions the author must answer for a safe merge. Tailor to this

+ diff — no generic checklists. Each question cites a specific part of the code.

+ (This is not `adversarial-challenge`; questions only, no threat-model writeup.)

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

+ - Three phases with headers, in order

+ - Do not restate the code beyond Phase 1

+ - Skip Phase 3 on trivial diffs (e.g. typo) and say so

+ - End with **Verdict**: `Approve` | `Approve with nits` | `Request changes` | `Block` — one-sentence justification