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. 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:** Plan-writing may run anywhere (`specs/` stays writable on shared branches); the feature branch/worktree is created at Execution Handoff via `using-git-worktrees`, before the first code edit. **Save plans to:** `specs/<slug>/PLAN.md` Artifact + slug convention: specs/README.md + .claude/rules/plan-format.md **Step 0 — load the format rule:** Read `.claude/rules/plan-format.md` now. It is path-scoped (not auto-loaded), and writing a brand-new PLAN.md does not trigger its `paths:` injection — this explicit Read is the load-bearing step. ## Input Artifacts Before writing anything, read both files from the spec directory: 1. `specs/<slug>/design.md` — the approved spec from brainstorming 2. `specs/<slug>/research-brief.md` — xia2's findings on what already exists The research brief determines what to reuse vs. build from scratch. If `research-brief.md` is missing, flag it to