writing-planslisted

# Writing Plans ## Overview Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits. Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well. **This plan is a disposable derivative of the spec** (where one exists): regenerated from it, thrown away after `subagent-driven-development` runs, never hand-maintained. Don't restate the spec's why/trade-offs — reference them; drift is prevented by regenerating the plan, not by keeping two documents in sync. Where no spec exists (a medium-sized task), keep this plan's own "why" to 2-3 lines and move straight to tasks. **Stay lean.** Don't add spec-kit constitutional gates, EARS templates, PR-FAQ sections, or pre-mortem/red-team role-play — the terminal Codex gate (see Execution Handoff) already covers that ground adversarially. **Announce at start:** "I'm using the writing-plans skill to create the implementation plan." **Context:** If working in an isolated worktree, the owned `subagent-driven-development` loop handles that isolation at execution time. **Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` - (User preferences for plan locati