A plan is an ordered set of Tasks grouped into phases. You approve it before code is written.
Use one when the work requires several changes in a specific order, or when you want to see the entire approach before committing to any part of it.
The lifecycle
Planning is a stage in its own right, not an instant transformation.
- Planning begins. The architect examines the codebase and drafts phases and Tasks.
- You review the draft. This is the cheapest point for making adjustments in the entire system.
- Approve, revise or reset. Approving releases it for execution; revising sends it back with your feedback; resetting starts the planning process 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 correct, revising it preserves what the architect learned about your codebase and applies your feedback. Resetting discards that information and starts again from scratch.
Reset when the entire approach is incorrect. Revise when the approach is right but the details are not. Revision is far cheaper, and the content of a rejected plan is not lost — it serves as input for the next attempt.
Controlling a running plan
A plan in progress can be paused, resumed or cancelled, and you can monitor its progress across all phases. Plans can also be cloned, which is a practical way to replicate a successful structure — such as applying a migration to a second service.
Completed plans can be archived to keep the active view clear.
One pull request, not one per Task
The Tasks in a plan do not each open a pull request. They work on their own branches and merge into a shared lane branch; that branch is turned into a single pull request against your base branch once the work is ready.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘You therefore review the complete feature in one go, with the entire change visible, rather than approving half-finished phases individually.
Cross-project plans are the exception: a Task belonging to a different project than the lane is submitted separately, resulting in one pull request per repository. A pull request cannot span two repositories.
Phases and parallelism
Phases define order, not concurrency. Tasks within a phase can run in parallel if capacity allows; the next phase waits for the current one to finish.
A plan with ten parallel-safe Tasks and one agent slot will still run them one at a time. Structure alone does not create capacity — see Capacity and agent slots.
Plan or Task?
You decide by choosing Phased work plan or One executable Task during the routing step. Nothing analyses your brief and decides for you.
The test is reviewability: one pull request that a colleague could read in one sitting constitutes a Task; anything requiring several ordered changes is a plan.
Guessing and opting for a Task when dealing with truly large work is the riskier mistake — the Task might run out of room midway through, wasting the run. Guessing and opting for a plan only costs you an approval step that you did not strictly need.
Delivery gates
A plan can include a delivery gate specifying what must be met before its output can move forward. See Quality gates.