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

# <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 (see below).
- **Validation:** exact commands to run, plus any manual checks.

## Phase 2: <name>
...

## Implementation log
(Empty at authoring time. The orchestrator appends one entry per phase:
date, phase, summary, validation results, review outcome, commit SHAs,
deviations, remaining risks.)

Sizing And Ordering Phases

• One phase = one implementer worker session. If a phase's Approach section needs subheadings to stay coherent, split it.
• Order by dependency, foundations first. A schema/migration phase is always its own phase (and in many repos its own PR — record that in Constraints).
• Phases that can run in parallel must have disjoint write scopes. Declare parallelizability explicitly in the phase list; the orchestrator will not guess.
• If a phase exists only to set up a later phase, say which one, so the orchestrator knows a deviation there propagates.