Brug ét fælles regelsæt med værktøjs­specifikke undtagelser

Hvis du bliver ved med at give et AI-kodeværktøj den samme rettelse, hører rettelsen sandsynligvis hjemme i kodebasen.

For Codex begynder faste projektinstruktioner normalt i AGENTS.md. Claude Code læser CLAUDE.md, men filen kan importere AGENTS.md. Dermed kan projektet have ét fælles regelsæt og nøjes med en lille tilpasning til de reelle forskelle mellem værktøjerne.

Forskellen betyder noget. Pakkekommandoer, grænser i arkitekturen, indholdsregler og krav til offentlige adresser ændrer sig ikke, fordi et andet kodeværktøj åbner kodebasen. Værktøjer til billeder, rettighedsmodeller, kørselsmiljø og værktøjsspecifikke kommandoer kan derimod være forskellige.

Start med et fælles regelsæt

Den fælles fil skal indeholde fakta og arbejdsaftaler, der gælder uanset hvilket kodeværktøj der er aktivt.

Nyttige instruktioner omfatter:

• Projektstruktur og grænser mellem moduler
• Pakkehåndtering og almindelige kommandoer
• Krav til tests, lint, typekontrol og build
• Regler for projektets teknologier og indhold
• Krav til tilgængelighed, sikkerhed, performance og SEO
• Offentlig funktionalitet der skal forblive stabil
• Områder der kræver godkendelse før ændringer
• Hvordan udførte og udeladte kontroller skal beskrives

På en virksomhedshjemmeside kan det betyde at bevare kontaktlinks, holde sprogversioner på linje, undgå ændringer af publicerede adresser uden viderestillinger og teste formularer, bookingflows eller betalingscallbacks efter relevante ændringer.

Det er viden om projektet, ikke et prompt til én bestemt model. Læg den i den fælles kilde i stedet for at vedligeholde samme regel i flere leverandørspecifikke filer.

Skriv konkrete regler

En instruktion skal påvirke en beslutning, som kodeværktøjet træffer. Vage formuleringer om kvalitet gør sjældent det.

Svag instruktion:

Skriv ren og skalerbar kode af høj kvalitet.

Konkret instruktion:

Brug eksisterende komponenter, før nye oprettes. Tilføj ikke afhængigheder
uden godkendelse. Kør pnpm check-types efter TypeScript-ændringer. Bevar
offentlige adresser, medmindre der tilføjes en viderestilling.

Den anden version beskriver handlinger og grænser, som kan kontrolleres i den færdige ændring. Det samme gælder indholdsarbejde: “skriv god tekst” er uklart, mens “bevar sidens søgeintention, brug første person ental, og opdatér den oversatte version” kan styre en konkret redigering.

Undgå at gøre filen til en fortegnelse over hele kodebasen. Værktøjet kan selv læse package.json, mapper og konfigurationsfiler. Brug instruktionsfilen til beslutninger, det ikke sikkert kan udlede: hvorfor en adresse ikke må ændres, hvilken kommando der er den rigtige, hvor forretningslogik hører hjemme, eller hvilke genererede filer der aldrig må redigeres manuelt.

Sådan finder Codex AGENTS.md

Codex opbygger en kæde af instruktioner, før arbejdet begynder. Ifølge OpenAIs officielle dokumentation om AGENTS.md læser værktøjet først globale instruktioner og går derefter fra projektets rodmappe ned mod den aktuelle arbejdsmappe. Instruktioner tættere på arbejdsmappen tilføjes senere og kan tilsidesætte bredere regler.

Det giver et praktisk hierarki:

• En global AGENTS.md til personlige arbejdsvaner på tværs af kodebaser
• En AGENTS.md i roden til regler for hele projektet
• En underordnet AGENTS.md, når en applikation eller pakke har reelt anderledes krav
• AGENTS.override.md, når de normale instruktioner skal erstattes på et bestemt niveau

Opdel ikke et lille projekt for tidligt. Én fil i roden er lettere at gennemgå. Tilføj først lokale instruktioner, når kommandoer, ansvar eller risiko faktisk er anderledes—for eksempel når et monorepo indeholder både frontend- og worker-kode med uforenelige kontrolkommandoer.

Lad CLAUDE.md importere de fælles regler

Claude Code læser CLAUDE.md, ikke AGENTS.md direkte. I Anthropics officielle dokumentation om projektinstruktioner anbefales det at importere en eksisterende AGENTS.md og derefter tilføje Claude-specifikke instruktioner.

En minimal fil kan være så kort:

@AGENTS.md

## Claude-specifikke undtagelser

- Tilføj kun regler, der er anderledes, fordi Claude bruger andre værktøjer
  eller kører i et andet miljø.

Importen er bedre end en kopi af det fælles indhold. Når en kommando til build, en regel for adresser eller en indholdskonvention ændres, skal den kun rettes ét sted. CLAUDE.md forklarer derefter kun, hvor Claude Code skal arbejde anderledes.

Claude Code understøtter også CLAUDE.local.md til private projektindstillinger og .claude/rules/ til modulære eller filafgrænsede regler. De filer kan være nyttige, men de bør ikke blive endnu en kopi af projektets fælles regelsæt.

Beskriv forskelle der påvirker arbejdet

Værktøjsspecifikke instruktioner er relevante, når forskellen ændrer, hvad værktøjet kan færdiggøre, hvilke ressourcer det må få adgang til, eller hvordan resultatet skal kontrolleres.

Fordel ansvaret efter værktøjernes muligheder

Ét kørselsmiljø kan have et godkendt værktøj, som et andet ikke har. Beskriv overdragelsen tydeligt i stedet for at opfordre til en erstatning, der bryder projektets standard.

En kodebase med artikler kan for eksempel kræve rasterbilleder fra en godkendt arbejdsgang til billedgenerering, som kun findes i Codex. Dens CLAUDE.md kan sige:

@AGENTS.md

## Claude-specifikke undtagelser

### Artikelbilleder

- Den godkendte arbejdsgang til artikelbilleder findes kun i Codex i dette
  projekt.
- Erstat den ikke med SVG, skærmbilleder, pladsholdere eller genbrugte billeder.
- Færdiggør arbejdet uden billeder, og oplys tydeligt, at billedfilen mangler.
- Billeder leveret af brugeren må fortsat forbindes med artiklen på normal vis.

Det er mere brugbart end en bred påstand om, at Claude aldrig kan arbejde med billeder. Funktioner kan ændre sig gennem plugins eller eksterne værktøjer; den holdbare oplysning er, hvilken arbejdsgang kodebasen godkender lige nu.

Kørselsmiljø og kontrol

Codex og Claude Code kan køre med forskellige begrænsninger for filer, netværk og processer. En fælles regel kan beskrive, hvilke kontroller ændringen kræver. Den værktøjsspecifikke fil kan forklare, hvordan det aktuelle kørselsmiljø påvirker arbejdet.

Ét miljø kan for eksempel kræve godkendelse, før afhængigheder hentes, mens et andet kan køre buildet direkte. Ingen af værktøjerne bør skrive, at en kontrol er gennemført, eller at en begrænsning forhindrede den, uden at det faktisk er konstateret.

Værktøjsspecifikke kommandoer

Læg ikke Claudes skråstregskommandoer, Codex-konfiguration eller navne på leverandørspecifikke værktøjer i den fælles fil, medmindre alle kodeværktøjer kan bruge dem. Behold kommandoer som Claudes /context i vejledningen til CLAUDE.md og Codex-specifik konfiguration i opsætningen til Codex.

Den fælles instruktion skal beskrive resultatet: kontrollér hvilke instruktioner der blev indlæst, gennemgå Git-status, eller kør projektets typekontrol. Tilpasningsfilen kan beskrive den værktøjsspecifikke metode.

Vejledning er ikke en teknisk spærring

En instruktionsfil påvirker værktøjets beslutninger. Den er ikke en teknisk sikkerhedsgrænse.

“Spørg før udrulning” hører hjemme i projektets vejledning, fordi den forklarer arbejdsaftalen. Hvis udrulning skal være umulig uden godkendelse, skal det håndhæves gennem rettigheder, adgangsoplysninger, hooks, CI eller kørselsmiljøet. Det samme gælder hemmeligheder, produktionsdatabaser, destruktive kommandoer og adgang til eksterne systemer.

Claudes dokumentation skelner mellem vejledning i CLAUDE.md og teknisk håndhævelse gennem rettigheder og hooks. Codex har tilsvarende særskilte indstillinger for begrænsninger og godkendelser. Brug instruktionsfilen til at forklare, hvordan projektet skal behandles, og brug miljøet til at begrænse det, der ikke må ske.

Kontrollér hvad værktøjerne har indlæst

Gå ikke ud fra, at en instruktionsfil er aktiv, blot fordi den findes.

Start en ny Codex-session i den ønskede mappe, og bed værktøjet opsummere de aktive instruktioner eller vise deres kilder. Det afslører også, om en underordnet undtagelse eller en global fil påvirker opgaven.

Kør /context i Claude Code, og kontrollér afsnittet med hukommelsesfiler. /memory er nyttig til at åbne og vedligeholde filerne, men /context viser, hvad den aktuelle session reelt har indlæst.

Afprøv derefter instruktionerne med en lille opgave, hvor resultatet kan kontrolleres. Hvis værktøjet bliver ved med at lave den samme fejl, bør du lede efter uklar tekst, modstridende regler, forkert afgrænsning eller en fil, der er blevet for lang til at være nyttig.

Vedligehold instruktionerne som kode

Projektinstruktioner skal gennemgås, fordi både kodebaser og værktøjer ændrer sig.

Opdatér dem når:

• En kommando, pakkehåndtering eller udrulningsproces ændres
• En kodegennemgang afslører den samme misforståelse igen
• En ny applikation eller et nyt kørselsmiljø giver andre begrænsninger
• Et værktøj får eller mister en funktion, som arbejdsgangen bruger
• En midlertidig undtagelse bliver permanent eller ikke længere er nødvendig

Fjern forældede regler i stedet for at tilføje rettelser for evigt. En kort fil med aktuelle beslutninger er mere nyttig end en lang historik over, hvordan projektet fungerede tidligere.

Den endelige struktur bør være enkel: ét fælles regelsæt, små værktøjsspecifikke tilpasninger og teknisk håndhævelse, hvor en påmindelse ikke er nok. Sammen med en kontrolleret arbejdsgang for Claude Code og Codex i en eksisterende kodebase og en særskilt AI-kodegennemgang giver det kodeværktøjerne brugbar kontekst uden at foregive, at instruktioner fjerner behovet for kontrol.