# 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.

<Callout>
  **Same context, same plan. Its own context, its own sub-plan.**
</Callout>

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 conversation, its own status, its own Specs,
and it pushes to your issue tracker on its own schedule.

It **inherits** its ancestors' Context automatically and read-only, so you never re-attach the same
document twice.

## 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.

<Cards>
  <Card title="Context sources" href="/docs/context-sources">
    What Context is, and how inheritance flows down the tree.
  </Card>

  <Card title="Plan lifecycle" href="/docs/plan-lifecycle">
    The statuses a plan moves through, and who moves them.
  </Card>
</Cards>