Agents read your code and your repository's instruction files. Context brings those memory files together with project notes, generated context and references.
For the reasoning behind what belongs here, read Project context in Concepts. This page covers managing it.
Repository memory files
Open Settings → Knowledge → Context and look under Repository sources. Coroid reads these files from the connected repository:
AGENTS.mdat the repository root: general agent instructionsCLAUDE.mdat the repository root: Claude instructionsGEMINI.mdat the repository root: Gemini instructions.cursor/rules: Cursor's project rules, either the directory of.mdcrule files (subfolders included) or a single legacy file
These are often called memory files. Their enabled contents are included in the agent's project context before work begins. The names do not restrict them to a particular model: enabled sources are combined for Coroid's agents.
Existing files appear with an Edit action, an estimated token count and a switch controlling whether agents receive them. Sources are enabled unless you explicitly disable them. If several files repeat or contradict each other, keep the sources you intend agents to follow enabled and disable the others.
Saving an edit to a project with a connected GitHub or GitLab repository opens a pull request with the change, on a new branch from the project's pull request base. Coroid does not commit to your default branch, and agents read the new version once the pull request is merged. A project whose repository Coroid hosts gets a commit instead. The editor says which before you save.
Coroid reads Cursor's rules the way Cursor applies them:
| Rule | What agents get |
|---|---|
alwaysApply: true | The whole rule |
globs set | The whole rule, with the files it applies to |
Only a description | The rule's path and description, so the agent reads it when it is relevant |
| None of these | Nothing: Cursor applies it only when someone mentions it |
A plain .md file in .cursor/rules is ignored, as Cursor ignores it. Rules in
the directory are edited in the repository, so that row has no Edit action.
Create means the file was confirmed absent from Coroid's repository checkout. If a read fails, the page offers Retry; an access failure does not mean the file is missing. Check that the file is committed to the connected repository's branch. For task execution, the agent reads the task's checkout, so changes to instruction files on that branch apply to the task.
Enabled memory files can import repository Markdown with @path, for example
@AGENTS.md in CLAUDE.md or @docs/conventions.md. Paths resolve relative to
the file containing the reference. Coroid follows nested imports, stops cycles,
and includes each file and each identical instruction body only once. Imports
inside code examples and email addresses are left alone. References outside the
repository are not loaded, and imports cannot bypass an explicitly disabled
repository source.
Only the listed sources are detected automatically. A nested AGENTS.md can
be included through an @ import; its directory scope is not inferred.
App contexts
Under App contexts, keep instructions and references stored in Coroid. Manual notes and generated project context can be enabled or disabled independently of repository files. Use these entries for information that belongs outside Git.
Adding context
Choose Add context 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.