review

name	review
description	Deep code review - Elixir idioms, Phoenix patterns, architecture, safety. Launches 3 parallel reviewers + plan-reviewer gate. Use when: review, review this, code review, check this code, review my changes, is this good, what do you think, code smells.

Code Review — Parallel Agents + Plan-Reviewer Gate

Reviews current changes for correctness, idioms, architecture, and Phoenix/LiveView patterns. Three parallel code-reviewer agents with focused scopes, aggregated findings, and a plan-reviewer critique before presenting fixes.

Workflow

Phase 1: Diff

Get the full diff and diff stat against main:

git diff main...HEAD
git diff main...HEAD --stat

Phase 2: Parallel Review

Launch 3 code-reviewer agents in parallel (single message, 3 Agent tool calls). Each gets the full diff but a focused mandate.

CRITICAL: Launch all 3 agents in the same message so they run concurrently.

Agent 1: Correctness & Safety

Focus: logic bugs, Ecto changeset errors, LiveView callback correctness, edge cases (nil, empty, missing records), query correctness, transaction safety.

Agent 2: Idioms & Architecture

Focus: Elixir idioms (multi-clause over if/else, no unless, no nested case), Phoenix patterns (contexts as boundary, thin LiveView, streams), DDD boundaries (Blog/Import/Export), module size <200 lines.

Agent 3: Completeness & Contracts

Focus: test coverage for new public functions, CLAUDE.md sync with actual structure, comment quality (WHY not WHAT), proper validations in changesets.

Phase 3: Aggregate

After all 3 agents return, merge findings:

1. Merge into unified tiers (Critical / Important / Minor / Positive)
2. Deduplicate same file:line across agents
3. Tag each finding with source: [safety], [idioms], [completeness]
4. Cap: max 5 Critical, 7 Important, 3 Minor
5. Verdict: any Critical or Important -> "Needs fixes"; only Minor/Positive -> "Clean with suggestions"

Phase 4: Plan + Critique

If Critical or Important findings exist:

1. Build a numbered fix plan
2. Launch a plan-reviewer agent to critique the fix plan
3. Incorporate critique: drop over-engineered fixes, add missed gaps
4. Present the critique-adjusted plan to the user

If only Minor findings: skip plan-reviewer, present review directly.

Phase 5: Present

Show the aggregated review to the user with verdict and fix plan if needed.

Phase 6: Implement

After user approves the plan:

1. Implement fixes in plan order
2. Run verification:

   mix test
   mix format --check-formatted
   mix compile --warnings-as-errors
   

3. Report results

Pipeline

/dev <issue> -> /review -> /commit -> /pr