A plan is an ordered set of tasks grouped into phases. You approve it before code is written.
Use one when the work needs several changes in a particular order, or when you want to see the whole approach before committing to any of it.
The lifecycle
Planning is a stage in its own right, not an instant transformation.
- Planning starts. The architect explores the codebase and drafts phases and tasks.
- You review the draft. This is the cheapest intervention point in the whole system.
- Approve, revise or reset. Approving releases it to execute; revising sends it back with your feedback; resetting starts planning over.
- Execution. Tasks run in order, respecting phase boundaries.
You can approve and execute in one step, or approve and start it later.
Revise rather than reset
When a plan is nearly right, revising it keeps what the architect learned about your codebase and applies your feedback. Resetting throws that away and starts again.
Reset when the whole approach is wrong. Revise when the approach is right and the detail is not. Revision is much cheaper, and a rejected plan's content is not lost — it is the input to the next attempt.
Controlling a running plan
A plan in flight can be paused, resumed or cancelled, and you can watch progress across its phases. Plans can also be cloned, which is the practical way to repeat a structure that worked — a migration applied to a second service, for instance.
Completed plans can be archived to keep the active view meaningful.
One pull request, not one per task
A plan's tasks do not each open a pull request. They work on their own branches and merge into a shared lane branch; that branch is promoted as a single pull request against your base branch when the work qualifies.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘You therefore review the assembled feature once, with the whole change visible, rather than approving half-finished phases one at a time.
Cross-project plans are the exception: a task belonging to a different project than the lane is promoted separately, so you get one pull request per repository. A pull request cannot span two repositories.
Phases and parallelism
Phases are ordering, not concurrency. Tasks within a phase can run in parallel if capacity allows; the next phase waits for the current one.
A plan with ten parallel-safe tasks and one agent slot still runs them one at a time. Structure does not create capacity — see Capacity and agent slots.
Plan or task?
You decide, by choosing Phased work plan or One executable task in the routing step. Nothing analyses your brief and decides for you.
The test is reviewability: one pull request a colleague could read in one sitting is a task; anything needing several ordered changes is a plan.
Guessing toward a task on genuinely large work is the riskier error — the task can run out of room partway through, wasting the run. Guessing toward a plan costs you an approval step you did not strictly need.
Delivery gates
A plan can carry a delivery gate governing what must be true before its output progresses. See Quality gates.