Agents read your code. Context is where you put what the code cannot say — the decisions, constraints and conventions that live outside it.
For the reasoning behind what belongs here, read Project context in Concepts. This page covers managing it.
Adding context
Open the project's Context section and add an entry. Each carries a title and body, and can be edited or removed later.
Good entries are short, specific and durable. Architecture decisions, style conventions, API contracts, ownership boundaries and explicit prohibitions all belong. Onboarding narrative and anything already obvious from the repository do not.
Keep entries separate and named
One entry per topic, titled for what it covers. "Error handling conventions" and "Frozen modules" are retrievable; a single entry called "Notes" containing both is not.
This matters because context is loaded selectively based on the work at hand — see Progressive skills. Well-separated entries let the right one load for the right task.
References
Alongside written entries you can attach references — links and documents that point at material held elsewhere. Use these when the authoritative copy lives in a wiki or design tool and you do not want a second copy drifting out of date.
Per-task context
Context on the project applies to everything in it. For material relevant to one piece of work — a ticket, a customer report, a design document — attach it to that task instead. A task-specific note left in project context becomes noise on every future task.
Keeping it true
Stale context is worse than missing context, because agents treat it as authoritative. When a convention changes, update the entry in the same change that changes the code.
Reviewing what is there
Read your context occasionally as if you were new. Entries accumulate, and the ones written during a migration that finished a year ago are now actively misleading.