En kontextfil talar om det agenten inte snabbt kan lista ut själv: hur saker körs, vilka konventioner som gäller, var gränserna går och vad den ska lämna orört. Håll den till en skärm. Lägg in kommandon, arkitektur och konventioner; håll hemligheter, hela kodbasen och önsketänkande regler utanför. Behandla den som kod — granska den i pull requests och radera rader som slutat stämma. En felaktig kontextfil är värre än ingen alls, för modellen litar på den.
Vad en kontextfil faktiskt är
När en agent börjar en uppgift känner den inte till ditt projekt. Den kan läsa filer, men läsning är långsamt och läckande — den provsmakar några mappar, gissar konventioner och fyller i luckorna med det som var vanligast i träningsdatan. Det är därifrån de skeva standardvalen kommer: testköraren du inte använder, mappstrukturen du övergav, importstilen din linter avvisar.
En kontextfil är dokumentet agenten läser först för att slippa den gissningen: en liten, högkoncentrerad brief som laddas in innan modellen gör något alls. Formatet spelar mindre roll — vad som står i den är hela saken. Monkeybases guide om att prompta för kod förklarar varför för mycket kontext skadar ett enskilt svar; den här artikeln handlar om den ena filen som laddas in i varje svar, och vad som får plats där.
Testet för varje rad
- Skulle agenten få det här fel utan raden? Om modellen redan gör rätt som standard är raden brus.
- Är det stabilt? Fakta som ändras varje vecka hör hemma i uppgiftsprompten, inte i standardfilen.
- Är det sant idag? En självsäkert fel instruktion följs självsäkert.
Vad som hör hemma i den
Det användbara innehållet delar in sig i fyra kategorier. Täcker din fil dessa och lite till är den redan bättre än de flesta.
pnpm test --filter web och inte npm test, förhindrar den raden ett dussin misslyckade försök.Result-typen i stället för att kasta undantag", "alla datum är UTC och lagras som ISO-strängar", "funktionskod ligger i features/, aldrig i lib/."db/migrations/; skapa en ny migration i stället" — förhindrar en hel kategori av skador.Vad som ska hållas utanför
En kontextfil misslyckas oftare av för mycket än för lite. Varje rad du lägger till spär ut resten, och modellen har inget sätt att veta vilka rader som är bärande. Ta bort allt som inte förtjänar sin plats.
Hemligheter och inloggningsuppgifter — filen läses av ett verktyg och committas ofta till repot; behandla den som offentlig. Hela kodbasen — att klistra in filträd och modullistor bränner bara kontext agenten hellre spenderar på den faktiska kod den behöver. Föråldrat önsketänkande — "vi migrerar till GraphQL" som stått där i ett år lär modellen att göra fel sak. Generella goda råd — "skriv ren kod, lägg till tester" är utfyllnad modellen redan kan; det tränger undan den specifika regel som faktiskt spelar roll.
Den svåraste att ta bort är regeln du skrev för ett problem som inte längre finns. Kontextfiler samlar på sig sådana: en workaround för en bugg som är fixad, en varning om en tjänst som är borta. De läses som ofarliga, men var och en är en instruktion agenten lydigt kommer att följa rakt in i en vägg.
Håll den kort
Det vanligaste misstaget är längd. En kontextfil som sträcker sig över flera skärmar slutar bli noggrant läst — av dig när du underhåller den, och i praktiken av modellen, som väger en fil på 2 000 ord annorlunda än en tajt fil. Sikta på något en ny kollega kan skumma på under en minut. Är den längre än så dokumenterar du förmodligen sådant koden borde dokumentera själv.
När ett avsnitt genuint behöver djup — ett komplext driftsättningsflöde, en icke uppenbar domänmodell — länka till ett eget dokument i stället för att klistra in det. Kontextfilen är ett register och en uppsättning skyddsräcken, inte manualen. De flesta verktyg stöder även nästlade filer: en katalogspecifik AGENTS.md som bara gäller när agenten arbetar i den undermappen, så att rotfilen förblir mager.
# Projekt En mening om vad det här är och vem som använder det. ## Kommandon Installera: pnpm install Utveckling: pnpm dev Test: pnpm test Lint: pnpm lint ## Arkitektur apps/web — React-UI. apps/api — Express-API. packages/types — delade typer. ## Konventioner - Datum är UTC ISO-strängar. - Använd Result-typen; kasta inte undantag för förväntade fel. ## Gränser - Redigera aldrig db/migrations/ — lägg till en ny migration. - Ändra inte det publika API:et i packages/types utan att flagga det.
Underhåll den som kod
En kontextfil är den enda dokumentationen i ditt repo som läses vid varje enskild uppgift. Det gör dess korrekthet ovanligt värdefull — och ovanligt dyr när den är fel. Lösningen är att sluta behandla den som en README du skrev en gång, och börja behandla den som kod som levereras med resten.
Provet: skulle en ny kollega förstå filen på en minut?
Ge kontextfilen till någon som inte skrivit den. Kan hon skumma den och peka ut vad som är kommando, arkitektur, konvention och gräns utan att fråga vad en rad betyder? Måste hon gissa är filen inte klar än.
Filen är en hävstång, inte en vägg
En kontextfil gör inte en modell noggrann, och den ersätter inte granskning. Det den gör är att ta bort en hel kategori av undvikbara misstag — de som kommer av att agenten inte visste något du helt enkelt kunde ha berättat. Det är hög avkastning för ett dokument som får plats på en skärm.
Skriv ner det agenten inte kan gissa sig till, lämna ute det den kan, och håll det hela sant. Belöningen är en agent som börjar varje uppgift redan riktad rätt i stället för att gissa — och betydligt färre promptar som går åt till att rätta samma antagande två gånger.