Agenterna läser din kod. Det täcker det mesta de behöver veta – men inte besluten som finns i någons huvud, på en wiki eller i ett samtal för två år sedan.
Projektkontext kombinerar instruktioner i repot med vägledningen du sparar i Coroid.
Instruktioner i repot är också kontext
Coroid läser minnesfiler, till exempel filer på rotnivå som AGENTS.md, CLAUDE.md och
GEMINI.md, samt den fil som stöds: .cursor/rules . Aktiverade källor inkluderas i agentens projektkontext innan arbetet börjar. @ kan importera andra instruktionsfiler. Upprepade importer, cirklar och identiska instruktioner inkluderas bara en gång. Du behöver inte kopiera instruktionerna till en kontextpost i appen.
I Inställningar → Kunskap → Kontext, Repo-källor vilka filer agenterna får, medan Appkontexter innehåller manuella anteckningar och genererad kontext som lagras i Coroid. Källor är aktiverade om de inte uttryckligen inaktiveras. Stäng av överlappande eller motstridiga instruktioner som du inte vill kombinera.
Instruktioner i repot följer med koden i Git. Appkontexter är användbara för vägledning och referenser som du har utanför repot. Båda behöver underhållas när en konvention ändras. Se Inställningar för projektkontext för information om sökvägar som stöds, filidentifiering och inställningar.
Vad Coroid kan lista ut på egen hand
Utifrån enbart repot kan agenterna se:
- vilka språk, ramverk och bibliotek som används
- hur projektet byggs, testas och körs
- befintliga mönster – hur fel hanteras, hur moduler struktureras och hur saker namnges
- vad som är beroende av vad
Du behöver inte dokumentera något av det här. Att upprepa informationen är bortkastat arbete och riskerar att bli inaktuellt jämfört med koden, som ändå är den mer tillförlitliga källan.
Vad agenterna inte kan dra slutsatser om
Koden visar vad du gjorde, men aldrig varför:
- att ett bibliotek valdes framför ett uppenbart alternativ av en anledning som fortfarande gäller
- ett mönster som ser ut som duplicerad kod men i själva verket är en avsiktlig skiljelinje
- en modul som ingen bör röra utan att prata med ett visst team
- konventioner ni har kommit överens om men ännu inte tillämpar någonstans
- begränsningar utanför kodbasen – regelefterlevnad, avtal eller en pågående migrering
Det här hör hemma i projektkontexten. Testet är enkelt: skulle någon som bara läser repot kunna lista ut det här? Om ja, utelämna det. Om nej, skriv ner det.
Repot visar vad
Agenterna läser repot för varje uppgift. Du behöver inte beskriva det igen.
- Språk, ramverk och bibliotek
- Hur det byggs, testas och körs
- Befintliga mönster och namngivning
- Vad som beror på vad
Du lägger till varför
Projektkontexten fångar upp sådant som annars bara finns i människors huvuden.
- Varför ett bibliotek valdes framför ett självklart alternativ
- Avsiktlig duplicering som skapar en tydlig gräns
- Moduler som ingen bör ändra utan godkännande från ett visst team
- Överenskomna konventioner som ännu inte har gjorts obligatoriska någonstans
- Yttre begränsningar: efterlevnadskrav, avtal och en pågående migrering
Testet: Kan någon lista ut det här genom att bara läsa repot? I så fall, utelämna det. Om inte, skriv ner det.
Lägg till kontext
Bifoga dokument, policyer och referenser under projektets Kontext sektion. Arkitekturanteckningar, beslutsloggar, stilguider och API-avtal fungerar alla bra.
Bra kontext är kortfattad och specifik. En introduktionsguide på 40 sidor, skriven för människor, består mest av berättande text. Det är de tre styckena med faktiska begränsningar som spelar roll. Plocka ut dem.
Uppgiftsspecifik kontext
Kontext som är kopplad till projektet gäller allt. Om något bara är relevant för en viss arbetsuppgift – ett ärende, ett designdokument eller en kundrapport – bifogar du det i stället till uppgiften.
Spara projektkontexten för sådant som gäller över tid. En uppgiftsspecifik anteckning i projektkontexten blir brus för varje framtida uppgift.
Håll kontexten uppdaterad
Inaktuell kontext är sämre än ingen kontext, eftersom agenterna behandlar den som en tillförlitlig källa. När en konvention ändras uppdaterar du kontexten i samma ändring som koden.
Om du märker att du upprepade gånger rättar samma sak i kommentarer vid omarbetning är det ett tecken på att något saknas i kontexten – eller att något i den är fel.