Review

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.