Agents read your repository. This covers most of what they require — but not the decisions that reside in people's minds, in a wiki, or in a conversation from two years ago.
Project context is where you enter the remaining details.
What Coroid determines automatically
From the repository alone, agents can identify:
- the programming languages, frameworks and libraries in use
- how the Project is built, tested and run
- existing patterns — how errors are handled, how modules are structured, and how items are named
- what depends on what
You do not need to document any of these details. Repeating them is a waste of time and risks creating information that becomes outdated compared to the code, which remains the most authoritative source.
What it cannot infer
The code reveals what you did, never why:
- a library chosen over an obvious alternative for a reason that still applies today
- a pattern that appears to be duplication but is actually a deliberate design choice
- a module that nobody should modify without consulting a specific team
- conventions that you have agreed upon but not yet enforced anywhere
- constraints from outside the codebase — compliance rules, contracts, or a migration currently in progress
This is what belongs in project context. The test is simple: could someone reading only the repository figure this out? If the answer is yes, omit it. If not, write it down.
Adding context
Attach documents, policies and references under the Project's Context section. Architecture notes, decision records, style guides and API contracts all work well here.
Good context is brief and specific. A 40-page onboarding guide written for humans contains mostly narrative; the three paragraphs within it that outline real constraints are the important ones. Extract those.
Per-task context
Context attached to the Project applies to everything. For details relevant to a single piece of work — a ticket, a design document, or a customer report — attach them to the task instead.
Keep project context for information that remains true over time. A task-specific note placed in project context becomes irrelevant noise for every future task.
Keeping it up to date
Context that has become outdated is worse than having no context at all, because agents treat it as authoritative. When a convention changes, update the context alongside the code changes.
If you find yourself repeatedly correcting the same issue in rework comments, it signals that something is missing from the context — or that something in it is incorrect.