plan-gate

Plan Gate

The one named gate for brainstorm → plan. The engine writes a plan scaffold whose required sections are enforced at plan→execute by the per-section gate — it blocks the transition and names any section left empty. This skill is the table of contents for filling them: it says which skill owns which section. It does not re-implement those skills.

When to Use

• Read this FIRST at brainstorm → plan, then invoke the per-section skills below — it is the single entry point that replaces the rival triggers the stage skills used to carry.
• Prerequisite: the plan already lives in the tracker plan.md. Getting it there (home + draft→tracker transport, never .claude/plans) is skill plan-discipline; this skill only fills the sections.
• Not a quality oracle: it routes, the owning skill judges. Don't put requirements/scope logic here.
• Trivial task: a section may be filled directly or marked N/A — <reason>; the engine gate enforces non-emptiness, not depth.

Workflow

Fill each required section of plan.md via its owning skill, top to bottom. The left column is the engine's PLAN_SECTIONS (a sync-test asserts this table stays identical to it — see tests/test_plan_gate.py):

Plan section	Owning skill / how to fill
Requirements	requirements-interview — per question: collect context → propose a cited best-guess → supervisor reviews.
Approach & counter	devils-advocate — conditional value-counter (explicit N/A — <reason> for trivial tasks): steelman the value → name its unstated assumption → counter it (needed? missed anything? another way?) → assess impact.
Scope & Out-of-scope	design-minimalism — every primitive justified by a current-epic use case; speculative ideas → Out of scope.
Steps	task-slicing — tracer-bullet slices, depends_on edges, expand–contract for wide refactors; then rack plan-extract to split into child tasks once headings stabilise.
Verification Protocol	Self-authored — the concrete checks that prove the work (tests, in-process composition, lint). A check that proves ABSENCE ("X no longer occurs") names three things: the pattern, the scope it runs over, and a known-present sample the pattern must still find — no sample, no verdict. See positive-control.

The three challenge stages run as a chain, not in parallel: requirements-interview states the value → devils-advocate challenges it (loop until it settles: is this needed? did we miss anything? is there another way?) → design-minimalism then minimises the means of what survives. That is why Approach & counter sits before Scope & Out-of-scope. The Approach & counter row is conditional (required=False): the engine never blocks execute on it, but a non-trivial plan should carry a real counter or an explicit N/A.

The gate fires on plan→execute and reopens nothing already passed. This skill's job is upstream: ensure each section has an owner so none is filled by guesswork or left blank for the gate to reject.

Completion

• Every required section in plan.md is filled by (or explicitly N/A'd through) its owning skill.
• The plan→execute transition passes the per-section gate (no EmptyPlanError).

Anti-Patterns

• Treating plan-gate as the judge — it is a router; the owning skill does the work.
• Copying requirements-interview / design-minimalism logic into this file — keep it a table of contents.
• Editing the section table without matching the engine's PLAN_SECTIONS — the sync-test fails loudly on drift.