/plan-review-gate

name: plan-review-gate
description: Automatic adversarial review gate that spawns 3 independent reviewers in parallel after any plan is drafted - all must PASS before presenting to user
auto_activate: true
triggers:
  - "plan drafted"
  - "implementation plan created"
  - after:writing-plans
  - after:orchestrated-execution:plan-validation

Plan Review Gate

**Core principle**: No plan reaches the user without surviving independent adversarial scrutiny.

Purpose

This skill automatically activates after any implementation plan is drafted, before presenting it to the user. It spawns three independent adversarial reviewers in parallel — Feasibility, Completeness, and Scope & Alignment — each as a fresh `Task()` instance. ALL three must PASS. On failure, the planner incorporates feedback and resubmits to entirely fresh reviewer instances. The gate iterates until consensus or max iterations.

---

Activation Triggers

This skill auto-activates when:

1. An implementation plan is drafted (by planner, explorer, or orchestrator) 2. The `writing-plans` skill completes a plan 3. The orchestrator's plan validation phase produces a plan for review 4. User explicitly requests: `/plan-review <path-to-plan>`

**Do NOT use for**: Trivial changes (single-file bug fixes, copy edits, config tweaks). The plan must have at least 2 work units or touch 3+ files to warrant gate review.

---

The 3 Adversarial Reviewers

Each reviewer is a fresh `Task()` instance with read-only access to the codebase. Reviewers produce binary PASS/FAIL verdicts backed by cited evidence. No suggestions — only findings.

Reviewer 1: Feasibility

Can this plan actually be executed against the real codebase?

| Check | Classification | Criteria | | --- | --- | --- | | File paths exist | BLOCKING if fabricated | Every file path referenced in the plan must exist (verify with glob/grep) | | Dependency ordering correct | BLOCKING if circular or forward-ref | Work units depend only on things that exist or are created before them | | Technical approach matches codebase | BLOCKING if incompatible | Proposed patterns, libraries, and conventions match what the codebase actually uses | | No unstated assumptions | BLOCKING if critical | Plan does not silently depend on services, env vars, or infrastructure that doesn't exist | | File scope realistic | WARNING | Each work unit's file scope is achievable without cascading changes |

Reviewer 2: Completeness

Does the plan fully address every aspect of the user's request?

| Check | Classification | Criteria | | --- | --- | --- | | All requirements mapped | BLOCKING if gap exists | Every user requirement maps to at least one plan item | | Verification steps defined | BLOCKING if missing | Each change has a way to verify it worked (test, manual check, or assertion) | | Edge cases considered | BLOCKING if obvious gaps | Error scenarios, empty states, boundary conditions addressed | | Rollback/backward compatibility | WARNING | Plan considers what happens if changes need to be reverted | | Cross-file integration points | BLOCKING if missing | Files that import/depend on changed files are accounted for |

Reviewer 3: Scope & Alignment

Is the plan right-sized for what the user actually asked?

| Check | Classification | Criteria | | --- | --- | --- | | Matches user request | BLOCKING if divergent | Plan solves what was asked, not what the planner finds interesting | | No scope creep | BLOCKING if present | No unnecessary features, abstractions, or refactoring beyond the request | | No under-scoping | BLOCKING if present | Obvious implications of the request are not omitted | | Complexity proportional | WARNING | Solution complexity matches problem complexity | | No simpler alternative missed | WARNING | Plan is not over-engineered when a simpler approach would suffice |

---

Reviewer Isolation Rules

These rules are **mandatory**. Violating any of them invalidates the review.

1. **Fresh instances only.** Each reviewer is a new `Task()` instance — never resumed, never given prior context. 2. **No cross-reviewer visibility.** No reviewer sees another reviewer's output. Ever. 3. **Read-only codebase access.** Reviewers can read files, run grep/glob, but cannot modify anything. 4. **No prior review findings on re-review.** When re-reviewing after iteration, completely fresh instances are spawned. The new reviewers have zero knowledge of what previous reviewers found. 5. **Input is limited to:** the plan text, the user's original request, and the codebase (via read-only tools).

**Why isolation matters:** Reviewers who see prior findings anchor on those findings instead of reviewing independently. Fresh instances prevent this bias and ensure each review cycle is a genuine independent check.

---

Workflow

1. Plan drafted by planner/explorer/orchestrator
2. Spawn 3 adversarial reviewers in PARALLEL (fresh Task() instances)
3. Collect all 3 verdicts
4. IF all PASS --> present plan to user with gate approval summary
5. IF any FAIL -->
   a. Planner reads ALL feedback from all reviewers
   b. Planner incorporates changes OR documents why feedback doesn't apply
   c. Spawn 3 NEW reviewer instances (never reuse -- prevents anchoring)
   d. Repeat from step 3
6. Max 3 iterations --> present plan with remaining issues noted for user decision

Phase 1: Spawn Reviewers (Parallel)

// Spawn all three reviewers in parallel for efficiency
const [feasibilityResult, completenessResult, scopeResult] = await Promise.all([
  Task({
    subagent_type: "general-purpose",
    description: "Feasibility review",
    prompt: feasibilityReviewPrompt(planText, userRequest),
  }),
  Task({
    subagent_type: "general-purpose",
    description: "Completeness review",
    prompt: completenessReviewPrompt(planText, userRequest),
  }),
  Task({
    subagent_type: "general-purpose",
    description: "Scope & Alignment review",
    prompt: scopeAlignmentReviewPrompt(p