review

name	review
description	Principle-grounded review of code changes, PRs, or plans. Triggers: "review", "critique".

Review

Thorough review grounded in project principles. Do NOT make changes — the review is the deliverable.

Use Tasks to track progress. Create a task for each step below (TaskCreate), mark each in_progress when starting and completed when done (TaskUpdate). Check TaskList after each step.

Step 1 — Load Principles

Read brain/principles.md. Follow every [[wikilink]] and read each linked principle file. These principles govern review judgments — refer back to them when evaluating issues.

Do NOT skip this. Do NOT use memorized principle content — always read fresh.

Step 2 — Determine Scope

Infer what to review from context — the user's message, recent diffs, or referenced plans/PRs. If genuinely ambiguous (nothing to infer), ask.

Auto-detect review mode from change size:

• BIG CHANGE (50+ lines changed, 3+ files, or new architecture) — all sections, at most 4 top issues per section
• SMALL CHANGE (under those thresholds) — one issue per section

Step 3 — Gather Context

For SMALL CHANGE reviews, read files directly in the main context — delegation overhead exceeds the cost of reading a few files.

For BIG CHANGE reviews, delegate exploration to subagents via the Task tool.

Spawn exploration agents (subagent_type: Explore) to:

• Read the code or plan under review
• Identify dependencies, callers, and downstream effects
• Map relevant types, tests, and infrastructure

Run multiple agents in parallel when investigating independent areas.

Step 4 — Gather Domain Skills

Check installed skills (.agents/skills/, .claude/skills/) for any that match the review's domain.

Invoke matched skills now — read their output and use domain guidance to inform your review.

For domains not covered by installed skills, use find-skills to search for a relevant skill.

Step 5 — Assessment Pipeline

Work through all sections in order. For each section, check against loaded principles.

1. Scope Check

If the review targets work against a plan phase:

• Read the plan phase that was assigned.
• Run git diff --stat and git log --oneline for the relevant commits.
• Flag files changed outside the plan phase's stated scope as scope violations.

If no plan phase applies, skip this subsection.

2. Architecture

• System design and component boundaries
• Dependency graph and coupling
• Data flow patterns and bottlenecks
• Security architecture (auth, data access, API boundaries)

3. Code Quality

• Code organization and module structure
• DRY violations — be aggressive
• Error handling patterns and missing edge cases (call out explicitly)
• Over-engineering or under-engineering relative to principles; consider redesign-from-first-principles
• Technical debt hotspots

4. Tests

• Coverage gaps (unit, integration, e2e)
• Test quality and assertion strength
• Missing edge case coverage — be thorough
• Untested failure modes and error paths
• New behavior must have new tests. Tests must assert outcomes, not implementation details.

5. Performance

• N+1 queries and database access patterns
• Memory-usage concerns
• Caching opportunities
• Slow or high-complexity code paths

Principle Compliance

For each changed file, check against loaded principles. Common violations:

• Bolted-on changes instead of redesign (redesign-from-first-principles)
• Missing verification (prove-it-works); for UI surfaces specifically, verify-in-the-browser
• Unnecessarily added complexity (subtract-before-you-add)
• Validation/error-handling scattered through internal code instead of pinned at the boundary (boundary-discipline)
• Flag soup or stringly-typed state where a discriminated union or branded type would rule out invalid combinations (make-illegal-states-unrepresentable)
• Knowledge sourced from spec docs without verifying against a real working reference (trust-real-code-over-spec)

Step 6 — Issue Format

NUMBER each issue (1, 2, 3...). For every issue:

• Describe the problem concretely with file and line references
• Assign severity: high (blocks acceptance), medium (worth fixing, multiple may block), low (style/minor)
• Present 2–3 options with LETTERS (A, B, C), including "do nothing" where reasonable
• For each option: implementation effort, risk, impact on other code, maintenance burden
• Give a recommended option and why, mapped to principles
• Ask whether the user agrees or wants a different direction

Severity Guide

• high: Incorrect behavior, missing tests for new behavior, scope violation on core files, principle violation that changes architecture.
• medium: Worth fixing but not blocking on its own. Multiple mediums may trigger rejection.
• low: Style, documentation, minor improvements. Note but don't block on these.

When using AskUserQuestion, label each option with issue NUMBER and option LETTER. Recommended option is always first.

Step 7 — Verdict

After presenting all issues, give an overall verdict:

• Accept: All checks pass, scope clean, tests present and passing.
• Accept with notes: Low-severity issues only. List them for optional follow-up.
• Revise: High-severity issues found. Include specific actionable feedback — reference the exact file, line context, and principle violated.

Interaction Rules

• Do not assume priorities on timeline or scale
• Do not make changes — present findings and wait for direction
• Present all sections together, then ask for feedback once at the end
• Per prove-it-works: if something can be tested, note how in the issue description