Coroid has four units of work. They nest, and choosing the right one is mostly a question of how big the work is and how much of it should run at once.
| Unit | Size | Ends in |
|---|---|---|
| Task | One change | One pull request |
| Plan | A feature, in phases | One pull request for the whole plan |
| Sprint | A block of work over time | Whatever its tasks produce |
| Lane | A stream of parallel work | The branch a plan's work integrates into |
Task
The atom. One task is one unit of work that produces one pull request, and it is what actually gets executed — plans, sprints and lanes are all ways of organising tasks.
If you can describe the outcome in a paragraph and a reviewer could read the result in one sitting, it is a task.
Plan
When work needs several changes in a particular order, it becomes a plan: an ordered set of tasks grouped into phases, which you approve before any code is written.
Use a plan when:
- later steps depend on earlier ones
- you want to see the whole approach before committing to any of it
- the work is a feature rather than a change
Approving the plan is the cheapest intervention point in the system. Rejecting an approach here costs a minute; rejecting it after three tasks have run costs three runs.
How a plan reaches your repository
A plan's tasks do not each open a pull request. They work on their own branches and merge into a shared lane branch, and that branch is promoted as one pull request against your base branch.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘So you review the assembled feature once, with the whole change in front of you, rather than approving half-finished phases individually.
The exception is work spanning several projects: a task belonging to a different project than the lane is promoted on its own, so cross-project plans produce a pull request per repository. That is unavoidable — a pull request cannot span two repositories.
Sprint
A time-boxed container for work, with its own metrics and timeline. Sprints answer "what are we doing this period, and how did it go" rather than "how is this feature built".
Use a sprint when you are coordinating a team's work over a period. Use a plan when you are decomposing one feature. They are not alternatives — a sprint can contain tasks that belong to several plans.
Lane
A lane is where a plan's parallel work integrates. Tasks target the lane's branch rather than your base branch, so several agents can progress at once without colliding, and the assembled result is promoted as a single pull request once it qualifies.
Where a plan is about order, a lane is about concurrency and integration. If you have capacity for several agents and work that does not strictly serialise, the lane is what lets them run together and still arrive as one reviewable change.
Choosing
The question is not how many pull requests you want — both a task and a plan arrive as one. It is how much work has to happen before the result is worth reviewing.
- Is this one change a reviewer could read in one sitting? Yes → task.
- Does it need several ordered changes before it makes sense as a whole? Yes → plan. Its lane handles running the pieces in parallel where they allow it.
Sprints sit alongside all of this as a planning and reporting layer.
What limits how much runs at once
Not the structure — the capacity. A plan with ten parallel-safe tasks and one agent slot runs them one at a time. See Capacity and agent slots.