| 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
