Review

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

Autonomous Session Mode

When this skill runs in a non-interactive Noodle execution session (for example Cook , Oops , or Repair ):

• Do not use AskUserQuestion. For each issue found, state the recommended action directly instead of presenting options.

• Write findings to a report file at brain/audits/review-<date>-<subject>.md in addition to session output.

• For high-severity issues, file a todo in brain/todos.md using the /todo skill.

• For low-severity issues, note them in the report but don't file separate todos.

• Conclude by committing the review report. Do not wait for direction.

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 (.claude/skills/ ) for any that match the review's domain. Common matches:

Domain Skill When

Frontend UI frontend-design

Web UI components, layouts, visual design

Codex delegation codex

Tasks delegated to Codex workers

For domains not listed above, use find-skills to search for a relevant skill.

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

Step 5 — Review Sections

Work through all sections, then present the full review. The user can redirect mid-stream if needed.

1. Architecture

• System design and component boundaries

• Dependency graph and coupling

• Data flow patterns and bottlenecks

• Scaling characteristics and single points of failure

• Security architecture (auth, data access, API boundaries)

2. Code Quality

• Code organization and module structure

• DRY violations — be aggressive

• Error handling patterns and missing edge cases (call out explicitly)

• Technical debt hotspots

• Over-engineering or under-engineering relative to foundational-thinking principles; consider redesign-from-first-principles

3. Tests

• Coverage gaps (unit, integration, e2e)

• Test quality and assertion strength

• Missing edge case coverage — be thorough

• Untested failure modes and error paths

4. Performance

• N+1 queries and database access patterns

• Memory-usage concerns

• Caching opportunities

• Slow or high-complexity code paths

Step 6 — Issue Format

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

• Describe the problem concretely with file and line references

• 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 foundational-thinking principles

• Ask whether the user agrees or wants a different direction

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

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