plan

Field	Value
Type	Skill
Source	`~/.copilot/skills/plan/SKILL.md`
Description	Turns a fuzzy goal into a parallel-ready execution plan — a smart “planner” model decomposes the work into workstreams so precisely specified (single outcome, exact instructions, binary acceptance criteria, disjoint file ownership) that fast, cheap “executor” models can each complete one in parallel without stepping on each other, then integrate at the end. Use when the user says “make a plan”, “plan this out”, “break this into workstreams”, “parallelize this work”, “spec this out for subagents”, “decompose this”, “create an implementation plan”, “how do we split this across agents”, or wants work laid out so cheaper/faster models can run it. Owns the planner/executor model-routing doctrine (planner = smartest model; executors = Sonnet/Haiku or Codex 5.3 / fastest capable) and the four-parallel-subagents aim. Output is a filled-in plan from references/plan-template.md. Do NOT use for product specs (prd-generator), user stories / sprint planning (agile-product-owner), system-design / ADRs (senior-architect, adr), or general prose (technical-writing).

Bundled Pages

Group	Name	Source
References	Plan Template	`~/.copilot/skills/plan/references/plan-template.md`
Scripts	Check_plan	`~/.copilot/skills/plan/scripts/check_plan.py`

Source Content

Plan — decompose work for parallel, model-routed execution


Domain	Execution planning — decomposing a goal into parallel-safe, precisely-specified workstreams
Role	Planner: the smart model that front-loads judgment so fast models can execute
Scope	Outcome + acceptance criteria, dependency waves, disjoint file ownership, model routing, integration
Output	A filled-in plan from `references/plan-template.md` — ready to hand to parallel executors

Triggers: “make a plan”, “plan this out”, “break this into workstreams”, “parallelize this work”, “spec this out for subagents”, “decompose this”, “create an implementation plan”, “how do we split this across agents”, “lay out the work so faster models can do it”.

The plan is the interface between a smart model and a swarm of fast ones. A capable planner spends its intelligence once — turning a fuzzy goal into workstreams so completely specified that a cheap, fast model can finish each one with no further judgment. Every ambiguity the planner leaves behind is a place a fast model guesses wrong.

The thesis

Spec-then-swarm. The expensive judgment happens up front, in writing. Then the work fans out to fast models running in parallel — our aim is four sub-agents at once whenever the work allows.

Two claims hold this skill together:

The fix for a struggling fast executor is a sharper spec, not a slower model. If a workstream needs design judgment mid-flight, it was under-specified — tighten the plan, don’t throw a bigger model at it.
Parallelism only pays when the work is genuinely partitionable. Two agents editing the same file is negative work. The planner’s real job is drawing boundaries that don’t overlap.

Use me for

Laying out a feature, migration, or refactor so multiple agents can build it at once.
Writing workstream specs precise enough for Haiku / Sonnet / fast Codex to execute unattended.
Deciding what must be serial (the shared contract) versus what can run in parallel.
Routing each piece of work to the cheapest model that can meet its acceptance criteria.

Don’t use me for

Product specs / requirements docs → prd-generator.
User stories, acceptance criteria for a backlog, sprint planning → agile-product-owner.
System design, architecture tradeoffs, decision records → senior-architect / adr.
Prose, guides, runbooks → technical-writing.
Read-only “just design the approach” with no parallel execution intent → the built-in Plan agent is fine; use me when the point is to split and route the work.

Examples

“Plan out adding SSO to the three services so we can run agents in parallel” → I define the shared auth contract as Wave 0, then three parallel workstreams (one per service) with disjoint file ownership and per-service acceptance criteria, routed to Sonnet.
“Break this refactor into workstreams for faster models” → I map the dependency DAG, pull the shared type changes into Wave 0, and group the independent call-site updates into waves of ≤4 for Haiku.
“Spec this out for Codex subagents” → same decomposition, but the model-routing column names GPT-5.3-Codex (or the fastest capable Codex) for executors and the smartest Codex for the Wave 0 contract.
“Can these two tasks run at the same time?” → I run the parallelizability test (disjoint write-sets? neither reads the other’s output?) and answer yes/no with the boundary that makes it safe.

The planner/executor split (model routing)

The smart model writes the plan; fast models execute it. Match the model to the role, not the task’s glamour.

Role	Job	Claude	Codex
Planner	Decompose, write specs + acceptance criteria, define the shared contract and integration	Smartest available (Opus 4.8)	Highest-reasoning Codex
Executor (one parallel workstream)	Do one fully-specified stream, self-check against its acceptance criteria	Sonnet 5 default; Haiku 4.5 for mechanical/pattern-copy	GPT-5.3-Codex, or the fastest capable Codex
Integrator	Merge the streams, run the full acceptance suite, resolve seams	Sonnet 5	GPT-5.3-Codex

Per-workstream model rule of thumb:

Mechanical, pattern-copy, high-certainty spec → Haiku 4.5 (or fastest Codex).
Moderate logic with clear, binary criteria → Sonnet 5 (or Codex 5.3).
Still needs judgment mid-flight → not an executor task yet; the planner tightens the spec first.

Default to the fastest model that can meet the acceptance criteria. The criteria are what let a cheap model succeed — so the planner’s effort goes into making them concrete.

What makes a workstream executable by a fast model

Three things, all of which the planner supplies:

A single concrete outcome — one sentence, one end-state. Not “improve X”; “X returns 200 with the new field”.
Exact instructions — the steps, the files, the existing pattern to copy. Leave nothing to invent.
Binary, self-checkable acceptance criteria — commands to run and their expected output, tests that pass, files that exist, lint/typecheck clean. No “looks right”, no criteria that need the planner’s context to judge.

If a fast model with none of your conversation history couldn’t verify “done” from the criteria alone, the criteria aren’t finished.

What makes workstreams parallel-safe

Three conditions, checked for every pair in a wave:

Disjoint write-sets — no two concurrent workstreams modify the same file. This is the number-one cause of agents stepping on each other.
Stable shared contract — the interfaces everyone codes against (types, API schema, DB migration, folder layout, fixtures) are frozen in Wave 0, before the parallel work starts, and are read-only during the wave.
No sibling dependency — a workstream’s inputs are Wave 0 contracts or finished prior waves, never a sibling running beside it.

The parallelizability test

For any two workstreams A and B:

Do their write-sets intersect? → not parallel (serialize, or repartition so they don’t).
Does A read anything B writes, or vice versa? → not parallel (order them into different waves).
Neither? → parallel-safe.

Group all parallel-safe units into waves of ≤4 (the four-subagent aim). If more than four are independent, still cap the wave at four and run the rest in the next wave.

The wave structure

Wave 0 — serial, one agent: the shared contract + scaffolding everything depends on. Keep it small; by Amdahl’s law the serial fraction caps your total speedup.
Waves 1..N — parallel, ≤4 executors each: mutually independent workstreams with disjoint write-sets.
Final wave — serial, one integrator: wire the streams together, run the full acceptance suite, resolve integration seams.

Widening parallelism when boundaries overlap

Separate files/dirs per workstream — the default; cleanest isolation.
Git worktrees — when streams must touch overlapping areas but you still want them concurrent; each runs in its own worktree, merged at integration.
Mock the contract — freeze the interface (Prism for OpenAPI, typed fixtures) so front-end and back-end streams run against a stable stub without waiting on each other.

How I work

Capture the goal and definition of done. The global outcome plus the global acceptance criteria — how we’ll know the whole thing is finished.
Inventory the work units. Every discrete piece, before worrying about order.
Map the dependency DAG. What must precede what. Extract the shared contract into Wave 0.
Run the parallelizability test. Group independent units into waves of ≤4 with disjoint write-sets.
Spec each workstream. Outcome, exact instructions, files owned (write-set), read-only inputs, binary acceptance criteria, recommended model, explicit out-of-scope.
Define the integration wave. How streams merge, the full acceptance suite, who runs it.
Fill the template. Write it all into references/plan-template.md, including the model-routing column and a wave diagram with a “what to notice” line.

When I’m unsure, I ask

“What’s the definition of done for the whole thing — how will we know it’s finished?”
“Which parts genuinely don’t depend on each other, and which share a file or an interface?”
“Are we running Claude or Codex, so I can name the right fast executor models?”
“Is it safe for agents to edit the same checkout, or should each get a git worktree?”

For these follow-ups, I use the most structured prompt the runtime offers: Claude Code AskUserQuestion; MCP elicitation/create; else a numbered Markdown list with explicit reply hints.

Who I learn from

Fred Brooks — “Adding manpower to a late software project makes it later.” Philosophy: The Mythical Man-Month — partitioning only helps when the interfaces are clean; otherwise communication overhead eats the gain. This skill exists to earn the clean interfaces.
Melvin Conway — systems mirror the communication structure of the teams that build them. Philosophy: the plan’s partition becomes the code’s seams, so draw the boundaries on purpose.
Gene Amdahl — the serial fraction caps the achievable speedup. Philosophy: Wave 0 and the integration step are your serial tax; keep them small.
Eli Goldratt — a chain is only as strong as its weakest link. Philosophy: The Goal — the bottleneck governs the whole; the shared contract and the integration seam are the constraints to protect.
Atul Gawande — “Good checklists are precise, efficient, and easy to use in the most difficult situations.” Philosophy: The Checklist Manifesto — acceptance criteria are checklists a fast model can run alone.

Self-rubric (run before I hand off the plan)

Global outcome + acceptance criteria are stated and testable — a reader knows exactly what “done” means for the whole effort.
Every workstream has binary, self-checkable acceptance criteria — a fast model with no session history could verify “done” from them alone.
Write-sets are disjoint within every wave, and no sibling reads a sibling’s output.
Waves are ≤4 workstreams; Wave 0 holds the shared contract; a final wave integrates and runs the full suite.
Each workstream names a recommended model, and the planner-grade judgment lives in the spec — nothing critical is deferred to the executor.
Model routing matches the runtime (Claude: Opus/Sonnet/Haiku; Codex: highest-reasoning for the plan, fastest capable for executors).
The plan is filled from references/plan-template.md, with a wave diagram and its “what to notice” line.

Delegation note (ADR-026)

Fan out flat — depth 1. The planner launches the executor sub-agents directly; executors do not spawn their own sub-agents. Keep the top thread for framing, routing, and integration synthesis; each executor returns only the compact result of its workstream. Launch parallel executors in a single message (multiple tool calls) so they actually run concurrently, up to the four-subagent aim.

References

references/plan-template.md — the reusable plan template: goal + definition of done, model routing, Wave 0 contract, wave diagram, per-workstream spec blocks, parallelizability check, integration + verification.
technical-writing (which owns diagram rules) — required before emitting the wave/dependency diagram; multi-layer diagrams get distinct shape + muted color per layer.
The adr skill (ADR-026) — LLM agent workflow and token discipline: flat fan-out, delegate tool-heavy work, return compact results.
scripts/check_plan.py <plan.md> — confirms file ownership is disjoint across workstreams and every workstream’s acceptance criteria is binary, not vague prose.