Plan Review Gate

Core principle: No plan reaches the user without surviving 3 adversarial checks.

How it works: This skill runs inline in the calling agent's context (no subagents). The calling LLM reads the plan and checks it against 3 criteria using its Read/Grep/Glob tools. Same LLM, same context — the value is structured adversarial framing, not agent independence.

When to Skip

Skip when plan is trivial: Single-file fix, copy edit, or config tweak with <3 changes → return GATE_PASS immediately.

The 3 Checks (Run in Sequence)

Check 1: Feasibility — Can this be executed against the real codebase?

Run these verifications using Read/Grep/Glob:

Criterion How to verify Blocking if

Plan file exists on disk Glob(pattern="{plan_file_path}") where plan_file_path is the path from the calling agent's context Returns 0 matches

File paths exist Glob(pattern="{path}") for every referenced file Any path returns 0 matches and doesn't exist

Dependency ordering Read plan phases — do later phases depend on earlier ones only? Circular or forward-reference dependencies

Technical approach matches codebase Read 1-2 existing files in the affected area Proposed patterns/libs differ from what codebase actually uses

No unstated infra assumptions Read plan for external services, env vars, DBs Plan silently assumes infra that doesn't exist

Check 2: Completeness — Does it cover the full request?

Read the user's original request and compare against the plan:

Criterion Blocking if

All requirements mapped Any user requirement has no corresponding plan item

Verification steps defined Any change has no way to verify it worked

Edge cases addressed Obvious error paths, empty states, or boundary conditions missing

Cross-file integration Files that import from changed files not accounted for

Check 3: Scope & Alignment — Is it right-sized?

Criterion Blocking if

Matches user request Plan solves different problem or adds unrequested features

No scope creep Extra abstractions, refactoring, or features beyond the request

No under-scoping Obvious implications of the request are omitted

Complexity proportional Solution is over-engineered for the problem

Workflow

1. Check if trivial → skip if yes (return GATE_PASS)
2. Run Check 1: Feasibility (use Read/Grep/Glob to verify file paths)
3. Run Check 2: Completeness (read request vs plan)
4. Run Check 3: Scope & Alignment (read request vs plan)
5. Collect findings:
   • Zero BLOCKING issues across all 3 checks → GATE_PASS
   • Any BLOCKING issue → GATE_FAIL with specifics
6. IF GATE_FAIL and iteration < 3: a. Present blocking issues clearly b. Revise the plan to address them c. Re-run checks (increment iteration counter) <!-- CC10X-M9: iteration counter is in-context only — not persisted to memory. If compaction occurs mid-retry, counter resets to 0 and gate may retry more than 3 times. Acceptable for now (gate still converges). -->
7. IF GATE_FAIL after 3 iterations → ESCALATION: emit a blocking review result and stop

Output Format

GATE_PASS

Plan Review Gate — GATE_PASS (iteration N of 3)

GATE_FAIL

Plan Review Gate — GATE_FAIL (iteration N of 3)

Blocking Issues (MUST ADDRESS before returning PLAN_CREATED)

• [Check]: [specific issue with evidence]

Escalation (3/3 iterations, still failing)

Plan Review Gate — ESCALATION REQUIRED (3/3 iterations exhausted)

Remaining Blocking Issues

[List by check with evidence]

→ Do NOT question the user from this skill. Return the blocking issues clearly so the planner can emit STATUS: NEEDS_CLARIFICATION and let the router handle user interaction.

Anti-Patterns

Anti-Pattern Why Wrong

Skipping file path verification Fabricated paths are the #1 plan failure mode

Treating GATE_FAIL as advisory GATE_FAIL must block PLAN_CREATED

Skipping for "simple" plans Read the skip criteria — only truly trivial plans qualify

Accepting GATE_PASS without evidence Each check needs a cited finding, not just "looks fine"