write-phase-plan

# Write Phase Plan ## Goal Produce a plan document that a phase-orchestrator run can execute without re-deriving structure. Each phase must be implementable by a worker that has no chat history: the phase section is the worker's entire brief, plus repo rules and the code itself. The plan is the source of truth during the run. The orchestrator updates phase status and appends log entries as it goes, so the document must be written to absorb that. ## Where The Plan Lives Follow the repo's convention for design docs (for example `plans/<author>/` in repos that define one). One markdown file per plan. Link out to the PRD/spec rather than duplicating it. ## Document Structure ```markdown # <Feature name> ## Overview One or two paragraphs: what is being built and why. Link the PRD/spec. ## Constraints Repo-wide facts every phase needs: commit/PR policy, validation commands, branch or worktree requirements, anything the orchestrator must not infer. ## Phases A short table or list: phase ID, name, depends-on, parallelizable-with. ## Phase 1: <name> - **Status:** Not started - **Depends on:** none | Phase N - **Objective:** one sentence, the outcome not the activity. - **Scope:** the files/modules this phase owns (its write scope). - **Out of scope:** adjacent work this phase must not touch. - **Approach:** implementation notes — key decisions already made, pointers to the code the worker should read first, known landmines. - **Acceptance criteria:** checkable statements ...