writing-planslisted

# Writing plans A plan is the set of decisions the implementer cannot make alone: which files, which names and signatures, which values from the spec, which tests prove each task. Write for a capable engineer who has never seen this codebase or conversation. **A plan longer than the code it describes has written the code instead.** Save the plan to `docs/plans/YYYY-MM-DD-<feature>.md`, or wherever the project keeps plans. ## Header ```markdown # <Feature> implementation plan > Execute with the executing-plans skill. Steps use `- [ ]` checkboxes. **Goal:** one sentence **Spec:** path to the approved spec **Architecture:** 2–3 sentences **Stack / constraints:** versions, dependency limits, platform floors, naming and copy rules. Exact values, copied from the spec or the repo. **Verification:** the project's commands (from CLAUDE.md or `.claude/verify.json`) ## Review focus Up to five inputs or failure modes the spec implies but no test yet covers, most likely first (empty input, concurrency, retries, offline, locale, large data…). Each gets a test in the task that owns it. ``` ## Map files first List the files to create or modify and each one's single responsibility, before defining tasks. Split by responsibility, not by layer. In existing code, follow its structure. ## Tasks A task is the smallest unit that has its own test cycle and could be rejected by a reviewer independently of its neighbours. Fold setup, config and docs into the task that needs them. ````markd