Context sources
The documents the agent reads before it plans: what to attach, at which level, and how inheritance works.
Context is the material the agent reads before it writes anything: your PRDs, research, support transcripts, regulations, API documentation, meeting notes.
It is the single highest-leverage thing you can give it. An agent with no Context writes a plausible plan about software in general; an agent with your Context writes a plan about your business.
Three levels, and they flow down
| Attach at | When |
|---|---|
| Team | True for everything you build: how you work, your tone, your standards. |
| Project | True for this product: its PRD, its architecture, its customers. |
| Plan | Only for this piece of work: the regulation, the vendor's docs, the ticket thread. |
Context flows downward. A plan sees its own sources, plus its project's, plus your team's. A sub-plan also inherits everything above it, read-only.
Nothing flows upward or sideways. A project does not read its plans' sources, and sibling plans never see each other's.
Choosing the level
Attach as high as the material is true, and no higher.
A document at Team level reaches every plan in every project, which is right for "how we write release notes" and wrong for "the Q3 pricing memo". The cost of attaching too high is not storage, it is that every unrelated plan now reads it.
If a piece of work needs its own sources, that is the signal it should be a sub-plan rather than more Specs in the current one. Specs cannot hold Context; plans can. See Sub-plans and dependencies.
Code is Context too
A connected repository is Context in every sense. The agent reads it to ground what it writes in the stack and conventions you actually have. It is set up differently, so it has its own page: Connecting a repository.