Review

---
name: review
description: "Code review — bugs, vulnerabilities, antipatterns."
context: fork
effort: slow
---

# /review — Code Review (SENAR-aligned)

Zero-tolerance review. Find every bug, vulnerability, antipattern, and performance issue.

`/review` is the explicit forced deep-audit surface. It requests
`tausik review route --task {slug} --deep` and executes the returned L3-deep
contract. Ordinary `/ship` consumes its package route and must not call this
multi-agent workflow unless that route has `deep=true`.
## Mindset

You are a hostile reviewer. Assume the code is broken until proven otherwise.
- Every line is suspect
- "It works" is not a defense

## Phase 0 — Load Context

Before reviewing, load role and project context:

1. **Check active task** (if any):
   ```bash
   .tausik/tausik task list --status active
   ```
   If active → `.tausik/tausik task show {slug}` → extract role, stack, **acceptance criteria**.

2. **Load role profile**: Read `harness/roles/{role}.md` — follow the role's /review modifiers.

3. **Load stack guide**: Read `harness/stacks/{stack}.md` — use the stack's review checklist.

4. **Load project conventions and dead ends**:
   ```bash
   .tausik/tausik memory search "convention"
   .tausik/tausik memory search "gotcha"
   .tausik/tausik memory list --type dead_end
   ```

## Algorithm

### 1. Determine Scope and Mode
- `$ARGUMENTS` = file path — review that file
- `$ARGUMENTS` = directory — review all source files in it
- `$ARGUMENTS` = "diff" or empty — `git diff HEAD~1` (last commit)
- `$ARGUMENTS` = "staged" — `git diff --cached`
- `$ARGUMENTS` contains "iterate" — enable Iterative Mode (see below). Combine with scope: `/review iterate`, `/review src/ iterate`
- `$ARGUMENTS` contains "lite" — enable Lite Mode (single `tausik-reviewer` sub-agent, structured JSON output, no 6-agent fork). See **Lite Mode** below. Combine with scope: `/review lite`, `/review src/ lite`

### 2. Read Code
Read every file in scope. Do NOT skim. Check `CLAUDE.md` for project rules.

### 3. Launch Parallel Review Agents

Launch **6 specialized review agents** in parallel via the Agent tool. Each agent receives the diff/files in scope, project context (CLAUDE.md, conventions, dead ends), and task info (goal, AC) if available.

> **Subagent model (phase=code-review):** run the 5 domain reviewers on **Sonnet 4.6**
> (`model="sonnet"` in the Agent call) — code review is a Sonnet-tier job. The
> **critic**'s adversarial synthesis benefits from a stronger reasoner — **Opus 4.8**
> (or Fable 5). Omitting `model=` is fine (the subagent inherits the session model);
> this is a cost/quality hint, not a hard requirement. Mapping:
> `docs/ru/research/model-routing-matrix.md`.

**Agent prompt template:**
> Read the agent instructions from `harness/skills/review/agents/{agent}.md`.
> Review the following files: {files_in_scope}.
> Task goal: {goal}. Acceptance criteria: {AC}.
> Stack: {stack}. Role: {role}.
> Project conventions: {conventions}. Dead ends: {dead_ends}.
> Return findings in the agent's output format.

Launch all 6 agents in a **single message** with parallel Agent tool calls:

| Agent | File | Focus |
|-------|------|-------|
| **quality** | `harness/skills/review/agents/quality.md` | Bugs, security, race conditions + SENAR 28-item checklist |
| **implementation** | `harness/skills/review/agents/implementation.md` | Goal achievement, AC coverage, wiring |
| **testing** | `harness/skills/review/agents/testing.md` | Test quality, coverage, fake test detection |
| **simplification** | `harness/skills/review/agents/simplification.md` | Over-engineering, unnecessary complexity |
| **documentation** | `harness/skills/review/agents/documentation.md` | Missing docs, changelog, CLAUDE.md |
| **critic** | `harness/skills/review/agents/critic.md` | Adversarial: find **3 weaknesses** the others miss (hidden failure modes, silent contract drift, assumption gaps) |

**Apply stack-specific review checklist** from the stack guide — include it in the quality agent prompt.

### 4. Collect, Deduplicate, and Verify

After all agents return:

1. **Collect** all findings from 5 agents into a single list
2. **Deduplicate** — if two agents flag the same file:line, merge into one issue with the higher severity
3. **Verify each finding** — read the actual code at file:line and confirm the issue exists:
   - If confirmed → mark as CONFIRMED
   - If false positive → mark as FALSE POSITIVE and discard
4. **Re-prioritize** — adjust severity if context changes the assessment

### 5. Run Quality Gates
```bash
python scripts/gate_runner.py review --files {files_in_scope}
```
- Gate results are appended to the review output
- Log results if task is active: `.tausik/tausik task log {slug} "Gates: {summary}"`

### 6. Compile Final Report

Merge all confirmed findings into the standard Output Format (see below).

### 7. Record Review Run (SENAR Rule 10.15)

The `/review` skill runs **6 adversarial agents** — this is an **L3 review** (external/adversarial reviewer, separate context from the implementer). Record it so ADR (Adversarial Defect Rate) can be tracked across the project.

```bash
.tausik/tausik review record \
  --task {slug} \
  --type L3 \
  --critical {N_critical} \
  --high {N_high} \
  --warnings {N_medium_plus_low} \
  --reason "{why each CRITICAL is CRITICAL — required when N_critical > 0}" \
  --author-model {model id of this session — it wrote the code} \
  --reviewer-model {model the reviewer agents ran on, e.g. sonnet} \
  --reviewer-context different-model \
  --reviewer-invocations 7 \
  --deep \
  --notes "{1-line summary or commit/PR url}"
```

An L3 record is refused when the two models are the same family, or when either is missing (SENAR Rule 4, github#157). If the agents inherited the session model, the pass was a separate context but not a separate model: record it as `--type L2`.

Notes:
- `--type L1` = author checklist with zero reviewer calls, `L2` = focused
  reviewer in a fresh context, `L3` = external reviewer on a different model
  family. This explicit skill is the L3-deep route.
- ADR is shown in `tausik metrics` once any L3 reviews exist.
- Severity follows the project scale in `docs/en/severity-scale.md` (SENAR 1.5 §10.15(f)). Your classification is a proposal; the supervisor who accepts a finding decides it.
- Skip if no active task — store as `--task <related-slug>` if reviewing arbitrary code (still surfaces in `tausik review list`).

### Fallback: Single-Pass Review

If the Agent tool is unavailable or agents fail, fall back to a **single-pass review** covering all 5 domains yourself. Use the severity scale of `docs/en/severity-scale.md`; in short:

**CRITICAL** — Null access, race conditions, injection, auth bypass, data loss
**HIGH** — Missing validation, error swallowing, hardcoded secrets, N+1
**MEDIUM** — God functions, duplication, magic numbers, over-engineering
**LOW** — Misleading names, dead code, missing docs

## Output Format

```
## Review: {scope}

Role: {role} | Stack: {stack}
Verdict: {FAIL|PASS WITH ISSUES|PASS}
Issues: {N} (Critical: {C}, High: {H}, Medium: {M}, Low: {L})

### Critical

**[C1] {Title}** — `{file}:{line}`
{problematic code}
Problem: {why this breaks}
Fix: {fixed code}

### High / Medium / Low ...

### SENAR Checks
- Scope creep: {clean / flagged items}
- Dead end violations: {none / repeated dead ends}
- AC coverage: {all met / gaps found}

### Summary
{1-2 sentences: overall assessment}
{Top 3 things to fix before merge}
```

**Suggest next:** If issues found: "Fix issues and re-run `/review`." If clean: "Run `/ship` to test, close task, and commit."

## Separate Context Review

**Key principle:** The implementer and reviewer should be different instances.

The parallel review agents (step 3) inherently provide separate context — each agent runs in its own fresh context with only the diff and project context. This satisfies the "separate context" requirement by default.

### When to additionally use a standalone subagent review

- When `$ARGUMENTS` contains "separate" or "independent" — launch one extra holistic review agent in addition to the 5 specialized ones
- When the diff touches >5 files — the extra holistic view catches cross-cutting issues the specialists might miss

## Adversarial Mode (built-in)

The **critic** agent is launched as one of the 6 parallel reviewers on every `/review` run — adversarial review is default, not an opt-in mode. The critic's job is explicitly to find **3 weaknesses the other 5 agents miss** (see `harness/skills/review/agents/critic.md` for its hunting grounds).

### Deep mode (extra pass)

When `$ARGUMENTS` contains "adversarial" or "deep", run **two critic passes** sequentially, feeding the first critic's findings into the second so it hunts for what even the first critic missed. Stop if the second pass finds only LOW severity.

### When to auto-escalate to deep mode

- Reviewing security-sensitive code (auth, payments, crypto, session handling)
- Diff touches >5 files across multiple modules
- User says "deep", "thorough", "hostile"

## Lite Mode

When `$ARGUMENTS` contains "lite", **skip the 6-agent fork** and invoke the single Claude-native sub-agent `tausik-reviewer` instead. Trade adversarial breadth for token cost: one consolidated review per file, structured JSON output, main context stays clean.

### When to pick Lite over the default

- Low-stakes diff (docs, comment-only changes, trivial refactor)
- Fast preview before a full `/review`
- Token budget concern (sub-agent main-context overhead is roughly 6× lower than the parallel-6 flow)

Skip Lite for security-sensitive code (auth, payments, crypto), >5-file diffs, or anything you would otherwise route through Adversarial deep mode — those still want the 6-agent breadth + critic.

### Algorithm

1. Resolve scope (same as step 1 of standard `/review`).
2. Read project context (CLAUDE.md, conventions, dead ends, active task) — same as Phase 0.
3. Invoke the sub-agent in a single tool call:
   ```
   Agent(
     subagent_type="tausik-reviewer",
     prompt="Review files: {scope}. Task goal: {goal}. AC: {AC}. Stack: {stack}. Role: {role}. Conventions: {conventions}. Dead ends: {dead_ends}.",
   )
   ```
4. Sub-agent reads `harness/skills/review/agents/quality.md` + `docs/en/security.md` + `docs/en/security-checklist.md` from disk at runtime, applies them, returns one JSON object: `{scope, critical[], high[], medium[], low[], meta}`.
5. Render the JSON in the **standard Output Format** (re-use the template in step 6 of standard flow).
6. Run quality gates (same as step 5).
7. Record the run as `--type L3` only when the reviewer uses a different model family from the author. A fresh separate context on the same model family is L2, not L3; record both model identities so the recorder can enforce that boundary.

### Fallback

If `tausik-reviewer` sub-agent is missing (`.claude/agents/tausik-reviewer.md` absent — bootstrap may not have copied it on legacy installs), fall back to standard 6-agent flow and emit a one-line warning.

## Iterative Mode

When `$ARGUMENTS` contains "iterate", run a review→fix→verify loop instead of a single pass.

### Algorithm

1. **Run standard review** (all phases above, including Separate Context / Adversarial if triggered)
2. **Classify results**: count CRITICAL + HIGH issues
3. **If 0 CRITICAL+HIGH** → emit final report, stop. **REVIEW_DONE.**
4. **If issues found** → fix all CRITICAL and HIGH issues in-place
5. **Log iteration** (if active task): `.tausik/tausik task log {slug} "Review iteration {N}: {fixed_count} issues fixed"`
6. **Re-review** — go to step 1, but scope is now only the files touched by fixes
7. **Repeat** until REVIEW_DONE or iteration limit reached

### Exit conditions

| Condition | Action |
|-----------|--------|
| 0 CRITICAL+HIGH issues | Stop. Emit final report with MEDIUM/LOW as advisories |
| 5 iterations reached | Stop. Emit warning + remaining issues list |
| Same issues persist across 2 iterations | Stop. Flag as "stalemate — manual intervention needed" |

### Iteration output

Each iteration produces a compact summary (not the full report):

```
### Iteration {N}
Fixed: {list of fixed issues}
Remaining: {C} critical, {H} high, {M} medium, {L} low
Status: {continuing | done | limit reached | stalemate}
```

The **final report** after the loop uses the standard Output Format with an added iteration summary header:

```
## Review: {scope} (iterative, {N} iterations)
...standard format...
### Iteration History
- Iteration 1: found {X} issues, fixed {Y}
- Iteration 2: found {X} issues, fixed {Y}
- ...
```

### Without active task

If no active task exists, iterative mode still works but logs a warning:
"No active task — iteration progress will not be logged to task history."

### When to suggest iterative mode

- After a standard review finds ≥3 CRITICAL+HIGH issues, suggest: "Run `/review iterate` to fix and verify all issues in a loop."

## Rules

- NEVER say "looks good" or "nice work"
- NEVER skip a section because "it's probably fine"
- If 0 issues found: "No issues found — request a second review."
- Prioritize: security > correctness > performance > style
- Log review result if task is active: `.tausik/tausik task log {slug} "Review: {verdict}, {N} issues"`
- **Document dead ends**: if the review reveals a pattern that doesn't work, add it: `.tausik/tausik dead-end "approach" "reason"`
- **Defect tracking**: if bugs are found in completed tasks, create fix tasks with `--defect-of`: `.tausik/tausik task add "Fix: description" --defect-of parent-slug --role developer`

## Gotchas

- **`git diff HEAD~1` shows nothing if nothing is committed** — check `git status` first.
- **Large diffs (>500 lines)** degrade review quality. Split into focused reviews.
- **Review your own generated code** — don't skip review just because you wrote it.