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:** This should be run in a dedicated worktree (created by brainstorming skill). **Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` - (User preferences for plan location override this default) ## Codebase-Read Gate (mandatory before any technical claim) Before mapping files, writing tasks, or making ANY technical claim about how the codebase works: use Grep, Glob, or Read to find ≥1 real piece of relevant evidence. Cite `path:line` in your first technical statement. This is what separates grounded plans from generic checklists. **Do NOT ask "what file should I look at?" — find it yourself.** | Request type | Action | |---|---| | Concrete symbol/file mentioned ("the auth handler is slow", "tools/foo.py is broken") | Grep for the symbol, Read the file, cite `path:line` | | Feature in an existing area ("add rate limiting", "refactor the DB