spec-planning

# Spec-First Planning <!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions truncated or dropped, which strips the very keywords a match depends on. --> Trigger phrases: "plan", "spec", "task breakdown", "acceptance criteria", "roadmap", "how do we split this" Before writing code: what will be done, how it counts as "done", and in what order to proceed become clear. ## Steps 1. **Purpose & scope:** the problem being solved in a single sentence; also write the out-of-scope explicitly (prevent scope creep). 2. **Split into vertical slices:** the smallest end-to-end working pieces (not horizontal layers). Each slice delivers value on its own. 3. **A contract for every task:** input · output · **measurable acceptance criterion** (testable) · estimated risk. 4. **Dependency graph:** which task waits on what; no cycles. **Bring the riskiest/most-unknown to the front** (fail-fast). 5. **Uncertainties:** assumption list + open questions; do not fill ambiguous spots with a guess, ask with explicit options. ## Output (docs/PLAN.md) ``` # <Feature> — Plan ## Acceptance criteria - [ ] <measurable outcome> ## Tasks (order) 1. <task> — criterion: <...> — dependency: <none/#n> — risk: <low/medium/high> ## Assumptions / Open questions - ... ``` ## Mark what you do not know — do not fill it in Where a requirement admits more than one reading, ...