# 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 [#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](/docs/sharing-a-plan).
## Sibling sub-plans cannot see each other [#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 [#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.
What Context is, and how inheritance flows down the tree.
The statuses a plan moves through, and who moves them.