Agents read your code. Context is where you store what the code cannot express — the decisions, constraints and conventions that exist outside it.
To understand why this belongs here, read Project context in the Concepts section. This page explains how to manage it.
Adding context
Open the Project's Context section and add an entry. Each entry has a title and body, and can be edited or removed later.
Well-written entries are short, specific and durable. Architecture decisions, style conventions, API contracts, ownership boundaries and explicit prohibitions all fit here. Onboarding narratives and anything already obvious from the repository do not.
Keep entries separate and named
One entry per topic, titled to reflect its content. "Error handling conventions" and "Frozen modules" are easily retrievable; a single entry called "Notes" containing both is not.
This matters because context is loaded selectively based on the current task — see Progressive skills. Well-separated entries allow the correct one to load for each task.
References
Alongside written entries, you can attach references — links and documents that point to external material. Use these when the official copy resides in a wiki or design tool and you do not want a second, outdated copy.
Per-task context
Project-level context applies to everything in the Project. For material relevant to a single piece of work — a ticket, a customer report, a design document — attach it to that task instead. A task-specific note stored in project context becomes irrelevant for all other tasks.
Keeping it up to date
Stale context is worse than missing context, as agents treat it as authoritative. When a convention changes, update the entry alongside the code changes.
Reviewing existing context
Read your context occasionally as if you were new to the Project. Entries accumulate, and those written during a migration completed a year ago may now be misleading.