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. **Announce at start:** "I'm using the writing-plans skill to create the implementation plan." **Context:** If working in an isolated worktree, it should have been created via the `nicopowers:using-git-worktrees` skill at execution time. <!-- nicopowers-learning-grounding:start --> If `docs/learnings/README.md` exists, read the index first and open only the notes relevant to this plan. If the index is absent, do nothing; do not create it or scan the directory while planning. <!-- nicopowers-learning-grounding:end --> **Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md` - (User preferences for plan location override this default) <!-- nicopowers-artifact-prototype:start --> ## Plain-Language Plans and Optional Behavior Prototypes Markdown is the canonical plan. Put the required plain-language overview in the plan header before technical task detail and metadata. Explain what is being made, why it matters, how it behaves for the user, the important choices a