writing-planslisted

# Writing Plans ## Overview A plan is a handoff artifact. Write it for a skilled engineer who has zero context for this codebase and must not guess binding decisions. Give the outcome, owned files, dependencies, interfaces, acceptance oracle, verification commands, and relevant docs. Use the senior-engineer register (see using-megapowers, Communication): declarative, self-contained, readable by an agent with no conversation context. DRY. YAGNI. TDD. **Save plans to:** `docs/megapowers/plans/YYYY-MM-DD-<feature-name>.md`. User preferences for plan location override this default. If the work needs an isolated worktree, megapowers:using-git-worktrees creates it at execution time. ## Input and Source Pass Before decomposing work, read the repository instructions. If present, read canonical `CONTEXT.md` (or the repository-named equivalent). Read relevant accepted ADRs when present, and matching project memories when present. Repository instructions govern process. `CONTEXT.md` supplies current domain vocabulary; accepted ADRs govern narrower design intent. Treat project memories as hidden historical hints and reverify them against current sources. Surface conflicts for resolution; never silently choose a source. ## Scope Check If the spec covers multiple independent subsystems, suggest one plan per subsystem. Each plan must produce working, testable software on its own. ## File Structure Before defining tasks, map which files will be created or modified and what each is