Plan executable work
Read planning, specification, artifacts, memory, and safety.
Entry gate
Require an approved spec.md. Stop if the design gate is absent, rejected, or stale relative to requirements.
Procedure
- Read the full specification, decisions, repository governance, relevant code and tests, and selected conventions or lessons.
- Map specification clauses to concrete components and file ownership.
- Build the dependency graph and wave map before writing tasks.
- Split work into atomic tasks using the exact contract in planning: at most five implementation files per task and three tasks per wave.
- Include a failing-test step for each behavior change and exact focused and broader verification commands.
- Mark
Parallel-safe: yes only for disjoint files and side effects. This metadata does not authorize worker creation.
- Check every objective, rule, quality criterion, prohibition, and definition-of-done item maps to at least one task or integration checkpoint.
- Present wave order, dependencies, file scope, risks, and verification strategy for approval.
- On approval, mark state
PLANNED; otherwise revise the plans without editing production code.
Output
Return STATUS, phase slug, wave count, task count, plan paths, gate result, and NEXT. Recommend $flow-execute only after explicit plan approval.
1---2name: flow-plan3description: Decomposes an approved specification into dependency-aware waves and atomic executable tasks with exact file scope, test-first actions, verification commands, and an execution gate.4---56# Plan executable work78Read [planning](../../references/planning.md), [specification](../../references/specification.md), [artifacts](../../references/artifacts.md), [memory](../../references/memory.md), and [safety](../../references/safety.md).910## Entry gate1112Require an approved `spec.md`. Stop if the design gate is absent, rejected, or stale relative to requirements.1314## Procedure15161. Read the full specification, decisions, repository governance, relevant code and tests, and selected conventions or lessons.172. Map specification clauses to concrete components and file ownership.183. Build the dependency graph and wave map before writing tasks.194. Split work into atomic tasks using the exact contract in [planning](../../references/planning.md): at most five implementation files per task and three tasks per wave.205. Include a failing-test step for each behavior change and exact focused and broader verification commands.216. Mark `Parallel-safe: yes` only for disjoint files and side effects. This metadata does not authorize worker creation.227. Check every objective, rule, quality criterion, prohibition, and definition-of-done item maps to at least one task or integration checkpoint.238. Present wave order, dependencies, file scope, risks, and verification strategy for approval.249. On approval, mark state `PLANNED`; otherwise revise the plans without editing production code.2526## Output2728Return `STATUS`, phase slug, wave count, task count, plan paths, gate result, and `NEXT`. Recommend `$flow-execute` only after explicit plan approval.