write-phase-plan git:20260829.3a8221dA

Immutable. This exact content is served forever at /api/v1/blob/878599ec966a17c4.

---
name: write-phase-plan
description: >-
  Writes or restructures an implementation plan in the format the
  phase-orchestrator skill consumes: dependency-ordered phases with explicit
  scope, acceptance criteria, validation commands, and status/log conventions.
  Use when the user asks to write a plan for phase orchestration, prepare a
  plan or PRD for delegated multi-agent implementation, or convert a spec,
  checklist, or design doc into implementable phases.
license: MIT
metadata:
  internal: true
---

# 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.

When restructuring an existing plan, preserve completed work, current phase
statuses, and implementation-log evidence unless the user explicitly asks to
reset them. Normalize the remaining work around that history instead of
rewriting the plan as a fresh run.

## 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
- **Topology:** default | a named non-default topology with disjoint parallel
  worker scopes and/or a loop stop condition, as applicable.
- **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 when authoring a new plan. Preserve existing entries when restructuring
a plan. The orchestrator appends one entry per phase: date, phase, summary,
validation results, review outcome, commit SHAs, deviations, remaining risks.)
```

## Sizing And Ordering Phases

- The default topology is one implementer worker session per phase. A phase
  may name a non-default topology such as disjoint batch workers, an audit
  fan-out, a bounded fix loop, or competing drafts. Define each worker's
  disjoint scope or the loop's stop condition; split the phase when that
  cannot stay concise.
- 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.

## Writing For A Context-Free Worker

The implementer sees the plan, the repo, and nothing else. So:

- Use standalone spec language. No "as discussed", "still", "instead of the
  old approach", or references to conversations that produced the plan.
- Name concrete things: file paths, function names, commands — not "the
  relevant helper" or "the usual checks".
- State decisions as decisions. If something is genuinely unresolved, mark it
  as an explicit open question and say who resolves it (the worker may decide
  in-scope questions; the orchestrator escalates cross-cutting ones).
- Put shared context in Constraints once rather than repeating it per phase.

## Acceptance Criteria

Each criterion must be checkable by the reviewer from the diff and the running
code, without asking the author:

- Good: "`POST /orgs/:id/invites` returns 403 for a non-admin member; covered
  by a route test."
- Bad: "Invites are properly secured."

Include the negative space: what must not change (existing behavior, public
contracts, performance characteristics) when regression there is a real risk.

## Status And Log Conventions

- Phase status vocabulary: Not started, In progress, Done, Partial, Blocked.
- The orchestrator owns status transitions and log entries during the run;
  the author sets new phases to Not started and preserves existing phase state
  when restructuring an active or completed plan.
- Keep the Implementation log section present, preserving existing entries,
  so run updates have a stable place to land.

## Anti-Patterns

- Phases split by activity (design/build/test) instead of by deliverable —
  every phase should end with validated, committable work.
- Two phases that edit the same files marked as parallel.
- Acceptance criteria that restate the objective instead of testing it.
- A plan that embeds the whole PRD — link it and keep the plan operational.
- Hidden sequencing: prose that implies an order the phase list doesn't state.