/plan — phased implementation plan
Goal: a plan an executor (you or a subagent) can follow without re-deriving context.
Do this
- For non-trivial work, delegate to the
harness-claude:planner agent, passing it the spec
(read .claude/planning/<slug>/SPEC.md if present — the slug is in .claude/STATE.md),
the reuse decision, and the objective/purpose (not just a one-line query).
- For small/linear work, plan inline using the same shape.
- Break work into phases/tasks: each small, independently verifiable, with an exit check.
Give each task an ID (
T1, T2, …), its write-set (files it will create/edit), a
depends_on list of prior task IDs, and the AC-n criteria it addresses — the
format /harness-claude:orchestrate and /harness-claude:verify consume (schema: docs/state-and-artifacts.md).
- Surface risks, dependencies, and ordering explicitly. Red-team the plan before
handing it off — assume it already failed and ask why; attack your own draft for
hidden assumptions and missing edge cases, not just the obvious risks. Note where
you'll need an architecture decision (
/harness-claude:architect) vs. where the path
is obvious.
- Flag parallelizable phases. From the per-phase file lists, mark any phase that writes
3+ independent files with disjoint write-sets and no cross-dependency as an
/harness-claude:orchestrate candidate. This is what makes /implement surface the parallel
fan-out offer instead of silently editing serially — if you don't flag it here, it's usually
missed there. Flag only genuine cases; if none qualify, say so.
Output
For non-trivial work, write .claude/planning/<slug>/PLAN.md (present a summary in the
reply too); for trivial work, the plan in the reply is enough (say so). Format:
## Plan: <title>
## Tasks
### Task T1: <goal>
- files: <write-set>
- depends_on: []
- addresses: AC-1, AC-2
- exit check: <test/build/behavior>
### Task T2: ...
## Risks & dependencies
## Parallelizable phases (if any) — tasks with 3+ independent files, disjoint write-sets → /orchestrate candidates
## Where /architect is needed (if any)
State
When you wrote a PLAN.md, patch .claude/STATE.md: phase: plan, status: done,
next_skill: /plan-check.
Orchestration note
This is the canonical sequential-phase flow (see rules/agents.md). Compact context
before heavy implementation.
Exit criterion
Every task has a write-set, depends_on, the AC-n it addresses, and a concrete exit
check. Then /harness-claude:plan-check (gate the plan before building) — or
/harness-claude:architect first if flagged.
1---2name: plan3description: Produce a phased, risk-assessed implementation plan from a spec. Use after /spec and /research, before writing code. Delegates to the harness-claude:planner agent for non-trivial work.4---56# /plan — phased implementation plan78Goal: a plan an executor (you or a subagent) can follow without re-deriving context.910## Do this111. For non-trivial work, **delegate to the `harness-claude:planner` agent**, passing it the spec12 (read `.claude/planning/<slug>/SPEC.md` if present — the slug is in `.claude/STATE.md`),13 the reuse decision, and the objective/purpose (not just a one-line query).142. For small/linear work, plan inline using the same shape.153. Break work into **phases/tasks**: each small, independently verifiable, with an exit check.16 Give each task an ID (`T1`, `T2`, …), its **write-set** (files it will create/edit), a17 `depends_on` list of prior task IDs, and the `AC-n` criteria it **addresses** — the18 format `/harness-claude:orchestrate` and `/harness-claude:verify` consume (schema: `docs/state-and-artifacts.md`).194. Surface risks, dependencies, and ordering explicitly. **Red-team the plan before20 handing it off** — assume it already failed and ask why; attack your own draft for21 hidden assumptions and missing edge cases, not just the obvious risks. Note where22 you'll need an architecture decision (`/harness-claude:architect`) vs. where the path23 is obvious.245. **Flag parallelizable phases.** From the per-phase file lists, mark any phase that writes25 **3+ independent files with disjoint write-sets and no cross-dependency** as an26 `/harness-claude:orchestrate` candidate. This is what makes `/implement` surface the parallel27 fan-out offer instead of silently editing serially — if you don't flag it here, it's usually28 missed there. Flag only genuine cases; if none qualify, say so.2930## Output31For non-trivial work, **write `.claude/planning/<slug>/PLAN.md`** (present a summary in the32reply too); for trivial work, the plan in the reply is enough (say so). Format:3334```35## Plan: <title>36## Tasks37### Task T1: <goal>38- files: <write-set>39- depends_on: []40- addresses: AC-1, AC-241- exit check: <test/build/behavior>42### Task T2: ...43## Risks & dependencies44## Parallelizable phases (if any) — tasks with 3+ independent files, disjoint write-sets → /orchestrate candidates45## Where /architect is needed (if any)46```4748## State49When you wrote a `PLAN.md`, patch `.claude/STATE.md`: `phase: plan`, `status: done`,50`next_skill: /plan-check`.5152## Orchestration note53This is the canonical **sequential-phase** flow (see rules/agents.md). Compact context54before heavy implementation.5556## Exit criterion57Every task has a write-set, `depends_on`, the `AC-n` it addresses, and a concrete exit58check. Then `/harness-claude:plan-check` (gate the plan before building) — or59`/harness-claude:architect` first if flagged.