Sub-plans and dependencies
When work belongs in this plan, when it needs its own sub-plan, and how to say one thing needs another first.
There is one rule for deciding whether new work belongs in the plan you are in or in a sub-plan of its own, and it is about Context, not about size.
Same context, same plan. Its own context, its own sub-plan.
Specs share their plan's Context. So work that needs its own background material (its own regulation, its own vendor API docs, its own research) belongs in a sub-plan, because a sub-plan is the thing that can hold sources.
A plan about checkout that grows a section on tax compliance is the usual example. The tax work needs the tax rules attached; the checkout work does not want them in every prompt. That is a sub-plan, not five more Specs.
What a sub-plan gets
A sub-plan is a plan in every respect. It has its own epic, its own conversation, its own status, its own Specs, and it pushes to your issue tracker on its own schedule.
When the agent splits work out, it writes the sub-plan up as it creates it: the epic that says what this piece of work is, plus its own Context. Documents already attached to the parent plan that belong with the split-out work move across and become the sub-plan's own. So opening a new sub-plan is picking up a plan, not starting a blank one.
On top of that it inherits its ancestors' Context automatically and read-only, so you never re-attach the same document twice.
Copying a sub-plan keeps it where it was: Create new plan, with same context puts the copy beside the original, under the same parent, so it starts with a copy of the documents that plan owns and keeps inheriting the parent's.
One thing a sub-plan does not get is sharing of its own. Who can see it is decided on the top-level plan and covers the whole tree, so opening Share on a sub-plan sends you there rather than offering settings that would change every branch. See Sharing a plan.
Sibling sub-plans cannot see each other
Two sub-plans of the same parent are isolated. Neither one's conversation knows the other exists, and that is deliberate: a plan that can see its siblings starts making claims about work you did not ask it to think about.
The one exception is when you create a dependency between them, below.
Needs first
Any plan or Spec can declare that it needs another one first. That is how you say "the API has to exist before the UI can call it".
Dependencies do three things:
- They order the work, and the order survives the push to your issue tracker as issue relations.
- They are cycle-checked. A dependency that would create a loop is refused when you make it, not discovered later.
- At plan level, a needs-first edge also imports that plan's Context and Specs, so the dependent plan can actually see what it is waiting on.
That import is direct only. If A needs B and B needs C, A sees B, not C.