/engineer-plan-review — Plan Simplicity Review

Review implementation plans through multiple simplification lenses to catch overengineering, YAGNI violations, and unnecessary complexity before any code is written.

When to Use

User says "review this plan", "check the plan", "simplify the plan"
After completing /engineer-plan and before starting /engineer-work
User suspects a plan is overengineered or too complex

Process

Step 1: Locate the Plan

Find the plan to review:

If $ARGUMENTS specifies a path, use that
Otherwise check docs/plans/ for the most recent plan
If no plan found, ask the user

Read the full plan. Also read any referenced specs in docs/tech-specs/ or docs/prds/ to understand what was actually requested.

Step 2: Launch Parallel Reviewers

Spawn ALL 4 reviewers IN PARALLEL using the Task tool. Send all Task calls in a single message.

Each reviewer receives the full plan content and any referenced spec content inline in their prompt.

YAGNI Reviewer

Task(subagent_type: "general-purpose", description: "YAGNI review of plan")
prompt: Review this implementation plan for YAGNI (You Aren't Gonna Need It) violations.

  [PASTE FULL PLAN HERE]

  [PASTE REFERENCED SPEC IF ANY]

  For each task in the plan, ask: "Is this required by the spec or is it speculative?"

  Flag tasks or subtasks that:
  - Build for hypothetical future requirements not in the spec
  - Add configurability or extensibility that isn't requested
  - Include abstractions for things that only have one concrete use
  - Add feature flags, toggle systems, or plugin architectures prematurely
  - Build admin tools, dashboards, or management UIs not in scope

  For each finding, return:
  - Task number and name
  - What's unnecessary and why
  - Suggested simplification (remove entirely, or reduce scope)

Complexity Reviewer

Task(subagent_type: "general-purpose", description: "Complexity review of plan")
prompt: Review this implementation plan for unnecessary complexity.

  [PASTE FULL PLAN HERE]

  [PASTE REFERENCED SPEC IF ANY]

  Look for:
  - Tasks that could be combined into simpler ones
  - Overly granular decomposition (tasks that are artificially split)
  - Unnecessary indirection layers (services wrapping services, adapters for single implementations)
  - Custom solutions where a library or built-in would suffice
  - Premature optimization tasks (caching, indexing, performance work before measuring)
  - Tasks creating abstractions when inline code would be clearer
  - Helper utilities or shared modules for one-time operations

  For each finding, return:
  - Task number(s) and name(s)
  - What's overcomplicated and why
  - Simpler alternative

Scope Reviewer

Task(subagent_type: "general-purpose", description: "Scope review of plan")
prompt: Review this implementation plan for scope creep beyond the spec.

  [PASTE FULL PLAN HERE]

  [PASTE REFERENCED SPEC IF ANY]

  Compare the plan against the spec (or stated requirements). Flag:
  - Tasks that go beyond what was specified
  - Error handling for scenarios that can't reasonably happen
  - Edge cases that are extremely unlikely and not in the spec
  - Multiple implementation options where the spec implies one
  - Testing tasks that test framework behavior rather than business logic
  - Documentation tasks beyond what's needed

  For each finding, return:
  - Task number and name
  - What exceeds scope and what was actually requested
  - Recommendation (remove, reduce, or defer)

Ordering & Dependencies Reviewer

Task(subagent_type: "general-purpose", description: "Dependencies review of plan")
prompt: Review this implementation plan for dependency and ordering issues.

  [PASTE FULL PLAN HERE]

  Look for:
  - Incorrect dependency ordering (task depends on something not yet built)
  - Missing dependencies (task assumes something exists that no prior task creates)
  - Unnecessary sequential dependencies (tasks marked dependent that could be parallel)
  - Tasks that should be merged because they always change together
  - Setup tasks that are heavier than needed

  For each finding, return:
  - Task number(s)
  - The ordering/dependency issue
  - Suggested fix

Step 3: Synthesize Findings

Collect all reviewer results and produce a unified review:

## Plan Review: [Plan Name]

### Summary
[1-2 sentence overall assessment: is this plan right-sized, slightly over-built, or significantly overengineered?]

### Recommendations

#### 1. [Short title]
**Type:** YAGNI / Complexity / Scope / Ordering
**Tasks affected:** #N, #M
**Issue:** [What's wrong]
**Recommendation:** [Specific change — remove task, merge tasks, simplify approach]
**Impact:** [What gets simpler if adopted]

#### 2. ...

### Tasks That Look Good
[List tasks that all reviewers agreed are well-scoped and necessary]

Deduplicate across reviewers — if multiple reviewers flag the same task, combine into one recommendation with the strongest reasoning.

Order recommendations by impact (biggest simplification first).

Step 4: Interactive Resolution

Present the review to the user, then for EACH recommendation, use AskUserQuestion:

"[Recommendation title]: [one-line summary]" (header: "Rec N")
- "Accept — update the plan" — Apply this simplification
- "Skip — keep as is" — The current plan is fine here
- "Discuss — I have context" — Let the user explain why it's needed

If the user chooses "Discuss", listen to their reasoning. If it justifies the complexity, skip the recommendation. If not, suggest a compromise.

Step 5: Update the Plan

If any recommendations were accepted:

Read the current plan file
Apply all accepted changes (remove tasks, merge tasks, simplify descriptions, fix ordering)
Write the updated plan back to the same file
Add a revision note at the top: **Revised:** YYYY-MM-DD after plan review (N simplifications applied)

If no recommendations were accepted, no changes needed.

Step 6: Handoff

Use AskUserQuestion:

"Plan review complete. What's next?" (header: "Next step")
- "Start building (/engineer-work)" — Execute the plan
- "Revise the plan further (/engineer-plan)" — Major rework needed
- "Done for now" — Save and close

Output

Review findings presented inline
Updated plan file (if changes accepted) at original path in docs/plans/

Next Steps

Ready to build? → /engineer-work
Need a full rewrite? → /engineer-plan
Want to review code after building? → /engineer-review