plan-draftlisted

# /plan-draft — Implementation Planning Use this skill to produce a structured implementation plan before writing any code. Can be invoked standalone (`/plan-draft`) or applied by the `planner` sub-agent during the `/feature` workflow. --- ## Context Gathering Before planning, collect all relevant context: - **External specs**: If the prompt references an external link or doc, fetch it before planning — the Requirements section must quote the source verbatim. - **Codebase**: Read any module-specific `AGENTS.md` files in directories likely to be affected, ADRs in `docs/adr/`, and relevant product docs in `docs/`. --- ## Planning Rules - **The Approval Summary is what the developer approves.** It is read on a phone, so constrain the units, not the total: goal in 1–2 sentences, one line per acceptance criterion, one line per key decision, one line per NEEDS_DECISION. There is no hard line cap — the per-item limits keep it short. If the acceptance criteria grow past ~10, treat that as a signal the task should be split into smaller slices, not that the summary should be longer. Each acceptance criterion must be user-visible behaviour, not implementation ("a visitor submitting an invalid form sees the error next to the field", not "add a guard clause in the controller"). Number each criterion `AC-<slug>-n`, where `<slug>` is derived from the current git branch name: strip one leading type prefix if present (`worktree-`, `feat-`, `feature-`, `fix-`,