Plan Work

Spine position: Step 3 — scope-work → slice-tasks → plan-work.

Produce a detailed, verifiable implementation plan in the active epic capsule directory (specs/epics/eNN-slug/). Output: a story spec .md file (countable-story-format) and a decoupled eNNsYY-tasks.yaml with runnable verify commands. "I think it works" is not a step.

HARD GATE — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, convert the task into "step → verify: <cmd>" pairs here before writing tasks — every task ships a runnable verify: or the plan is not done.

RECURSIVE DISCIPLINE — This lifecycle applies to EVERY task, including updating these skills. Never skip planning because a task is "meta" or "just documentation."

Pre-flight

Read: release-plan.yaml, product/SCOPE_LATEST.yaml, active epics/<capsule>/epic.yaml, tech-architecture/tech-stack.md, product/GLOSSARY_LATEST.yaml.

ZOOM-OUT MANDATE (v1.17.0) — If modifying an existing module: (1) State the module's purpose. (2) Name its callers. (3) List its contracts. Cannot answer all three? Stop — scope is misunderstood.

If this plan touches an existing module, run assess-impact first to understand blast radius.

DISCOVERY MANDATE (v1.18.0) — For external API integration, verify the API signature via local docs or search and quote at least one technical detail in the step's context.

MULTIPLE INTERPRETATIONS (HARD GATE) — If the task admits ≥2 valid interpretations, list them and get a user decision before drafting any steps.

COMPLEXITY PUSHBACK (HARD GATE) — Every new abstraction MUST include a one-sentence "Reason for Depth." If it can't be filled non-trivially, the abstraction is premature — use inline code instead.

SLOPCHECK (HARD GATE) — For every external package, tag it [OK], [SUS], or [SLOP]. [SUS]/[SLOP] require human approval before execution.

Invocation modes

• Default: full plan with zoom-out mandate, impact assessment, slopcheck
• --fast: Skip zoom-out and impact assessment. Use for tasks under 3 BCPs with no module interface changes.

Process

Timing: bash scripts/bp-timing.sh start plan-work at invocation; bash scripts/bp-timing.sh end plan-work before handoff.

1. Explore — Use Explore subagent to understand affected modules, existing test patterns, similar prior art, and dependencies.
2. Draft steps — Break implementation into the smallest possible steps where each step leaves the codebase working, has one observable outcome, and can be verified with a single command. Red-flag check: name any rationalization you caught before moving to step 3.

3. Write capsule story spec + tasks — Output two files inside the active epic capsule. See REFERENCE.md for file formats and the plan-template. Each task MUST include a risk: field (P0 | P1 | P2 | P3) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (specs/tech-architecture/eNN-TEST_PLAN_LATEST.md) exists, read it and inherit its P0/P1 risk classifications and scenario IDs (SC-eNNsYY-P0-NN). Each task optionally includes a security: field (none / low / medium / high) sourced from the epic's specs/security/epics/<id>/THREAT_MODEL.md. Tasks with security: medium or security: high MUST include "no new security findings in affected paths" in their verify steps. Each task should also include an allure: block to drive test reporting: severity: maps risk to Allure severity (P0→critical, P1→high, P2→normal, P3→minor), and categories: is a list of relevant tags like "Security Review", wave names, or test categories (see REFERENCE.md for the full template).

   Requirement delta tags (e45s29): When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before/after content:

   Tag	When	Required content
   ADDED	New requirement	Full requirement text
   MODIFIED	Changed behavior	Before: prior behavior · After: new behavior
   REMOVED	Retired requirement	Before: what existed · After: (removed) + rationale
   RENAMED	ID or title change only	Before: old ID/title · After: new ID/title

   Net-new stories (greenfield) use ADDED only. MODIFIED/REMOVED/RENAMED without before/after blocks fail the plan-work gate.

4. Verify step format — Every step MUST follow: N. <What to do> → verify: <runnable command>. See REFERENCE.md for good/bad examples.

4a. Cross-artifact consistency pass (HARD GATE — e45s04) — Before handoff, run:

bash scripts/lib/plan-consistency-check.sh specs/epics/<capsule>/

Print CRITICAL / HIGH / MED findings. CRITICAL or HIGH blocks code generation — fix capsule artifacts first. MED requires explicit user acknowledgment.

4b. tasks.yaml failing ledger (e45s06) — Every new task entry starts with status: failing. Only flip to status: passing after its verify: command exits 0 during develop-tdd or verify-work. Never pre-mark passing at plan time.

5. Review with user — Confirm step order, granularity, and that verify commands are runnable in this project.

Lifecycle Gates (e45s09)

After writing capsule tasks, suggest kickoff-branch (if not already on a feature branch) then build-epic, execute-plan, or develop-tdd.

Verify

→ verify: test -f scripts/lib/plan-consistency-check.sh && TASKS=$(grep -l '^spec:' specs/epics/*/*-tasks.yaml 2>/dev/null | sort | head -1) && test -n "$TASKS" && bash scripts/lib/plan-consistency-check.sh "$(dirname "$TASKS")" >/dev/null 2>&1

Handoff

Gate: READY -> next: kickoff-branch Writes: state.yaml handoff.next_skill = kickoff-branch