AGENTS.md Opsætning: 60.000+ Repos I 13 Trin [2026]

Din Claude Code-session ignorerer testkommandoen. Cursor foreslår ændringer der bryder linting. Copilot-agenten commiter direkte til en genereret mappe, fordi den aldrig fik at vide, at mappen var genereret. De fleste teams løser det ved at skrive den samme instruktion fire gange, én for hvert værktøj. Det er præcis det problem, AGENTS.md blev bygget til at fjerne: én fil, som stort set alle AI-kodeagenter kan læse, uanset om teamet bruger Codex, Claude Code, Cursor eller Copilot. Denne guide viser dig, trin for trin, hvordan du skriver, tester og vedligeholder en AGENTS.md-fil, der rent faktisk styrer agenternes adfærd, med et komplet eksempelprojekt du kan kopiere direkte ind i dit eget repo. Guiden hører hjemme i vores bredere dækning af AI-kodeværktøjer, hvor vi løbende går i dybden med de assistenter og agenter, danske og nordiske udviklerteams rent faktisk bruger i hverdagen.

Hvad er AGENTS.md, og hvorfor er den blevet standarden

AGENTS.md er en almindelig Markdown-fil, du lægger i roden af dit repository. Den beskriver, hvordan en AI-kodeagent skal opsætte, teste og ændre projektet, uden proprietær syntaks og uden krav om frontmatter eller et fast skema. Formatet opstod i 2025 omkring OpenAI Codex og Sourcegraphs agent Amp. Ifølge det officielle AGENTS.md-websted voksede standarden frem gennem et samarbejde mellem Codex, Amp, Googles Jules, Cursor og Factory, og specifikationens GitHub-repository, agentsmd/agents.md, blev offentliggjort i august 2025.

Den 9. december 2025 blev formatet doneret til Linux Foundations nye initiativ, Agentic AI Foundation, for at sikre langsigtet, leverandøruafhængig styring. Det viste sig at være det rigtige tidspunkt. I august 2026 rapporterede det officielle websted, at mere end 60.000 open source-projekter havde taget filen i brug, op fra omkring 20.000 tidligere på året, ifølge flere uafhængige gennemgange af formatet. Selve specifikationens GitHub-repository blev opgjort til 23.991 stjerner og 1.815 forks pr. 30. august 2026 i en rapport om formatets udbredelse. Tallene bør læses som øjebliksbilleder, for stjerner og repo-tællinger ændrer sig løbende, men retningen er tydelig: AGENTS.md er gået fra nichekonvention til de facto-standard på under to år.

Pointen med filen er enkel. I stedet for at et team vedligeholder separate instruktioner til hvert AI-værktøj, med al den vedligeholdelsesbyrde og de modstridende regler det medfører, samler AGENTS.md de portable dele ét sted: opsætning, test, kodestil, ændringsregler og sikkerhedsgrænser. Værktøjsspecifik adfærd hører stadig til i det enkelte værktøjs egen fil, men det generelle “sådan arbejder man i dette repo” behøver kun skrives én gang.

Det, der for alvor driver udbredelsen, er, at de fleste teams i dag ikke bruger ét AI-kodeværktøj, de bruger tre eller fire samtidig. En udvikler kører Cursor i editoren, en anden bruger Claude Code i terminalen, og CI-pipelinen kalder GitHub Copilots coding agent på pull requests. Før AGENTS.md skulle hvert af de værktøjer fodres med sin egen instruktionsfil, ofte skrevet af forskellige personer på forskellige tidspunkter, hvilket næsten garanteret endte med modstridende regler. Med en fælles fil i roden får hele teamet samme udgangspunkt, uanset hvilket værktøj den enkelte udvikler foretrækker den dag.

Før formatet fandtes, løste de fleste teams problemet ad hoc. Nogle skrev instruktionerne ind i selve README’en og håbede, at agenten ville finde dem mellem installationsvejledning og badges. Andre limede det samme afsnit ind i fire forskellige konfigurationsfiler og glemte konsekvent at opdatere tre af dem, når reglerne ændrede sig. Begge tilgange virker i et lille projekt med én udvikler, men skalerer dårligt, så snart flere personer og flere værktøjer rører den samme kodebase. AGENTS.md løser ikke problemet ved at være smartere end de tidligere løsninger. Den løser det ved, at nok værktøjer blev enige om at lede efter det samme filnavn på det samme sted.

Forudsætninger: dette skal du bruge

Du behøver ikke meget for at komme i gang, men få ting på plads gør trinene nedenfor markant nemmere at følge:

• Git 2.40 eller nyere, samt skriverettigheder til roden af dit repository.
• Mindst ét AI-kodeværktøj installeret, for eksempel OpenAI Codex CLI, Claude Code (version 2.1.277 eller nyere for native AGENTS.md-understøttelse), Cursor eller GitHub Copilots coding agent.
• Node.js 20 eller nyere, hvis du følger eksempelprojektet i denne guide. Skift kommandoerne ud, hvis dit projekt bruger et andet sprog eller en anden runtime.
• Adgang til projektets CI-opsætning (for eksempel GitHub Actions), hvis du vil gennemføre automatiseringstrinnet til sidst.
• Cirka 40-50 minutter, afhængigt af hvor stort dit repository er, og hvor mange nestede AGENTS.md-filer du ender med at skrive.

Trin 1: Opret AGENTS.md i projektets rod

Opret filen i roden af repositoriet, ved siden af README.md. Navnet er case-sensitivt, og de fleste værktøjer leder specifikt efter “AGENTS.md” i store bogstaver. Start med en minimal skeletstruktur, du bygger videre på i de næste trin:

# AGENTS.md

## Overview

## Setup

## Development workflow

## Testing

## Code style

## Change guidelines

## Pull requests

## Security

## Definition of done

Commit filen med det samme, selv i skeletform. En tom eller ufuldstændig AGENTS.md er stadig bedre end ingen fil, fordi de fleste agenter aktivt leder efter den, før de begynder at arbejde.

Trin 2: Beskriv projektoversigt og mappestruktur

Under Overview skriver du, hvad projektet gør, hvilke tjenester eller pakker det består af, og hvilke mapper der er vigtige. Undgå generel markedsføringstekst. En agent har brug for at vide, hvor koden bor, ikke hvorfor produktet er godt. Skriv typisk 3-6 linjer, der peger på src/, tests/, docs/ eller tilsvarende, og nævn eksplicit, hvis dele af repoet er genereret automatisk eller tilhører et separat build-system. Det er her, du forebygger den klassiske fejl, hvor en agent redigerer en genereret fil i stedet for kildefilen, fordi den aldrig fik at vide forskellen.

Tommelfingerreglen er, at hvis en ny udvikler ville have brug for informationen i sin første dag på projektet, hører den til her. Nævn hvilket sprog og hvilken runtime-version projektet er bygget på, om det er en monolit eller består af flere selvstændige services, og om der findes en separat mappe til infrastrukturkode eller deployment-scripts. Er projektet i gang med at migrere fra én arkitektur til en anden, for eksempel fra en monolit til mikroservices, er det værd at nævne det kort, så agenten ikke foreslår mønstre, der hører til den gamle struktur.

Trin 3: Tilføj setup- og installationskommandoer

Setup-sektionen skal indeholde de eksakte kommandoer, en agent kan køre for at få projektet op at stå fra en frisk clone. Skriv rigtige, kørbare kommandoer i et kodeblok, ikke en beskrivelse i prosa:

## Setup

npm install
cp .env.example .env
npm run db:migrate

Hold kommandoerne opdaterede. En forældet installationskommando er værre end ingen kommando overhovedet, fordi agenten vil forsøge at bruge den og fejle på en måde, der er svær at fejlfinde uden kontekst.

Trin 4: Definér udviklings-workflowet

Development workflow beskriver, hvordan man kører projektet lokalt, starter afhængige services og genstarter efter ændringer. Hvis projektet kræver en database, en cache eller flere samtidige processer, skal det stå her, ikke gættes af agenten. Nævn også, om der findes et Docker Compose-setup eller en dev container, agenten kan bruge i stedet for at installere afhængigheder direkte på værtsmaskinen. Har du allerede standardiseret på isolerede udviklingsmiljøer til AI-agenter, er det værd at krydshenvise til den opsætning, så nye teammedlemmer ikke ender med to konkurrerende måder at køre projektet på.

Beskriv også, hvordan man ser ændringer i praksis, for eksempel hvilken port en lokal server lytter på, og om der findes hot reload, så agenten ikke unødigt genstarter processer manuelt efter hver ændring. Har projektet flere miljøer, for eksempel et separat setup til at teste mod en staging-database, så nævn forskellen kort. En agent, der ved præcis, hvordan udviklingsmiljøet fungerer, bruger markant færre forsøg på at få en ændring til at virke lokalt, før den går videre til test.

Trin 5: Skriv testinstruktioner agenten kan bruge

Dette er den sektion, der oftest bliver skrevet for vagt. “Kør testene” fortæller ikke en agent, hvilken testsuite, hvilket miljø eller hvilke flag der er relevante. Vær konkret:

## Testing

npm test -- --runInBand
npm run lint
npm run typecheck

Hvis projektet har flere testniveauer, for eksempel enheds- og integrationstest, så adskil dem tydeligt, og angiv hvilke der forventes at køre grønt før en commit, og hvilke der kun kører i CI. En agent, der ikke ved, hvilken kommando der er den “rigtige”, vil ofte gætte forkert og rapportere falsk succes.

Trin 6: Fastlæg kodestil og lint-regler

Under Code style skal du ikke genskrive hele style-guiden i prosa. Peg i stedet på formatteren og linteren, projektet allerede bruger, og lad værktøjet håndhæve reglerne automatisk. Skriv kun de konventioner, et værktøj ikke kan udlede selv, for eksempel navngivningsmønstre for filer, foretrukne mappestrukturer for nye moduler, eller hvornår man bruger funktionskomponenter frem for klasser. Jo mere af reglerne der ligger i en faktisk linter-konfiguration, jo mindre er der at vedligeholde i selve AGENTS.md.

Et konkret eksempel: skriv ikke “brug camelCase til variabler”, hvis ESLint allerede håndhæver det og fejler builds, der ikke overholder reglen. Skriv i stedet ting som “nye React-komponenter placeres i src/components, ét modul pr. fil” eller “brug altid den delte fetch-wrapper i src/lib/api.ts frem for at kalde fetch direkte”, som er beslutninger, en linter ikke kan gætte sig til.

Trin 7: Sæt ændringsregler og no-go-zoner

Change guidelines fortæller agenten, hvilke filer der er trygge at ændre, og hvilke der kræver ekstra forsigtighed. Nævn eksplicit API-kontrakter, der ikke må brydes uden en migrationsplan, databaseskemaer, der kræver en separat migration, og tredjepartsintegrationer, hvor en fejl rammer produktion direkte. Har projektet dele, der bevidst er “frosne” eller under udfasning, så skriv det her. Uden den kontekst behandler agenten al kode som lige tilgængelig for ændringer.

Det er også her, du beskriver afhængigheder mellem services. Kalder frontend’en et internt API, der samtidig bruges af en mobilapp eller et andet team, skal det stå eksplicit, så en agent ikke ændrer et endpoint-svar uden at forstå, at det rammer mere end den kodebase, den lige nu arbejder i. Jo mere af den slags implicit viden, der bliver skrevet ned, jo mindre er risikoen for, at en umiddelbart lille ændring får utilsigtede konsekvenser andre steder i systemet.

Trin 8: Krav til pull requests

Pull request-sektionen beskriver, hvad der skal være på plads, før en agent kan åbne eller markere en PR som klar til review. Typiske krav er, at alle tests i Testing-sektionen er kørt og bestået, at commit-beskeden følger projektets konvention, at et CHANGELOG er opdateret, hvis projektet har et, og at større ændringer inkluderer en kort beskrivelse af, hvorfor ændringen blev lavet, ikke kun hvad der blev ændret. Uden disse krav ender teams typisk med PR’er, der teknisk set virker, men mangler den dokumentation, et menneske ville have skrevet automatisk.

Nogle teams vælger desuden at kræve, at agenten selv opsummerer, hvilke dele af koden den er usikker på, i stedet for at fremstå mere sikker, end den er. Det er en simpel regel at tilføje, og den gør reviewerens arbejde markant lettere, fordi opmærksomheden kan rettes mod de dele af ændringen, agenten selv flagger som usikre, i stedet for at gennemgå hele diffen med samme grundighed.

Trin 9: Skriv sikkerhedsafsnittet

Security-sektionen er den, flest teams springer over, og den, der gør mest skade at mangle. Skriv eksplicit, at agenten aldrig må committe hemmeligheder eller adgangsnøgler, aldrig må svække autentificering eller autorisation for at få en test til at bestå, og altid skal behandle ekstern input som utroligt. Nævn specifikt, at sikkerhedstjek i CI ikke må deaktiveres som en genvej. Husk samtidig, at AGENTS.md selv normalt bliver committet til repositoriet og er synlig for alle med adgang, så filen må aldrig indeholde reelle nøgler, tokens eller interne URL’er, kun regler for, hvordan man håndterer dem.

Arbejder projektet med persondata, bør sikkerhedsafsnittet også nævne det eksplicit. Skriv, at agenten ikke må logge eller udskrive rå persondata i fejlbeskeder, at test- og seedfixtures skal bruge syntetiske data frem for kopier af rigtige kundeoplysninger, og at ændringer i adgangskontrol eller dataadgang altid kræver menneskelig godkendelse, uanset hvor lille ændringen ellers virker. Det er en billig linje at skrive og en dyr fejl at mangle.

Trin 10: Definér “definition of done”

En kort “Definition of done”-liste giver agenten et konkret tjekpunkt til at vurdere, om en opgave er færdig, uden at et menneske skal spørge “er du sikker?” i hver eneste session. Typisk indhold er, at tests, lint og typecheck kører grønt, at dokumentation er opdateret, hvor relevant, og at ændringen ikke introducerer nye advarsler i build-outputtet. Denne sektion er kort, men den er den, der oftest afgør, om en agent stopper for tidligt eller fortsætter unødvendigt længe.

Trin 11: Nested AGENTS.md i et monorepo

Har projektet flere pakker eller services i samme repository, kan du lægge en ekstra AGENTS.md i hver undermappe. Rodfilen holder de fælles regler, mens den nestede fil beskriver det, der er specifikt for netop den pakke, for eksempel en anden testkommando eller et andet build-værktøj. De fleste af værktøjerne, der understøtter formatet, lader instruktioner tættere på den fil, agenten redigerer, supplere eller overskrive rodfilens regler, men den præcise arvefølge er værktøjsspecifik, så tjek dokumentationen for netop det værktøj, dit team bruger. OpenAI Codex’ dokumentation beskriver desuden en 32 KiB-grænse på instruktionsfiler samt en AGENTS.override.md, der kan bruges til midlertidige, højere-prioriterede regler under for eksempel en migrering.

Et monorepo med en frontend og et separat API kunne for eksempel se sådan ud:

repo-rod/
  AGENTS.md              # fælles regler: sikkerhed, PR-krav, definition of done
  packages/
    web/
      AGENTS.md           # frontend-specifik: npm run dev, Playwright-tests
    api/
      AGENTS.md           # backend-specifik: migrations, integrationstests

Rodfilen holder det, der gælder for hele repoet, mens hver pakkes egen fil kun beskriver det, der afviger. Undgå at gentage de samme sikkerhedsregler i alle tre filer. Skriv dem én gang i roden, og lad de nestede filer koncentrere sig om det, der er unikt for netop den pakke.

Trin 12: Test filen med et rigtigt AI-værktøj

Før du stoler på filen, så test den. Åbn et af dine kodeværktøjer i repositoriet, og bed det udføre en lille, afgrænset opgave, for eksempel at tilføje en ny test og køre testsuiten. En agent, der læser AGENTS.md korrekt, vil typisk bekræfte, at den har fundet filen, og bruge de kommandoer, du har angivet, i stedet for at gætte. Et output kan for eksempel se sådan ud:

$ codex "tilføj en test for login-endpointet og kør testsuiten"

Reading AGENTS.md... found 10 sections
Using setup command from AGENTS.md: npm install
Using test command from AGENTS.md: npm test -- --runInBand

Running tests...
  PASS  tests/auth/login.test.ts
  12 passed, 0 failed

Ready for review.

Ser du i stedet, at agenten gætter en anden testkommando, eller slet ikke nævner filen, er det første tegn på, at enten værktøjsversionen er for gammel, eller at filen ligger det forkerte sted.

Gentag testen med mindst to forskellige værktøjer, hvis teamet bruger mere end ét. Det er ikke ualmindeligt, at én agent læser filen korrekt, mens en anden ignorerer den, typisk fordi de er på forskellige versioner, eller fordi det ene værktøj kræver en anden filplacering for nestede regler. Find de forskelle nu, mens du kun tester en enkelt, lille opgave, i stedet for at opdage dem midt i en større ændring, hvor det er sværere at se, om problemet er filen eller agenten.

Trin 13: Automatisér vedligeholdelse med CI

En AGENTS.md, ingen vedligeholder, forfalder hurtigt. Den mest effektive løsning er et simpelt CI-tjek, der fejler, hvis kommandoerne i filen ikke længere kan køres, for eksempel fordi et script er blevet omdøbt. Et minimalt eksempel i GitHub Actions kan se sådan ud:

name: agents-md-check
on: [pull_request]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Kør kommandoer fra AGENTS.md
        run: |
          npm install
          npm test -- --runInBand
          npm run lint

Jobbet er ikke andet end de samme kommandoer, du allerede har skrevet i filen, kørt i en ren container. Går det i stykker, ved du med det samme, at agenterne i repoet også vil løbe ind i det samme problem.

Bedste praksis: sådan skriver du regler agenter rent faktisk følger

De 13 trin ovenfor giver dig en komplet fil, men kvaliteten af den enkelte sektion afgør, om agenterne rent faktisk retter sig efter den. Et par gennemgående principper går igen på tværs af dokumentationen fra de værktøjer, der understøtter formatet:

• Hold filen kort og handlingsorienteret. Fortæl agenten, hvad den skal gøre, ikke projektets historie eller baggrunden for arkitekturvalg, der ikke påvirker den daglige kode.
• Brug kommandoer, der rent faktisk virker lige nu. Test dem selv, før du skriver dem ind, og opdatér dem, så snart et script bliver omdøbt eller flyttet.
• Beskriv den valideringsproces, en agent skal følge, før den præsenterer en ændring som færdig. Uden det tjekker mange agenter kun det, der er nemmest at tjekke, ikke det, der faktisk betyder noget.
• Adskil rodfilens generelle regler fra pakke-specifikke regler i nestede filer, så roden forbliver stabil, selv når enkelte pakker ændrer sig hyppigt.
• Foretræk konkrete eksempler frem for vage formuleringer. “Kør npm test — –runInBand” er brugbart. “Sørg for at teste ordentligt” er det ikke.
• Undgå at duplikere værktøjsspecifik adfærd. Hold den slags i det pågældende værktøjs egen fil, og brug AGENTS.md udelukkende til det, der er reelt portabelt mellem værktøjer.

Ingen af disse principper kræver særlig værktøjsviden. De handler i bund og grund om at skrive til en meget bogstavelig læser, der ikke selv kan spørge ind til, hvad du mente, hvis en instruktion er tvetydig. Er du i tvivl om, hvorvidt en sætning er konkret nok, så læs den højt og spørg dig selv, om en ny praktikant uden forudgående kendskab til projektet ville kunne handle på den uden at stille et opklarende spørgsmål først. Kan de ikke det, kan agenten som regel heller ikke.

AGENTS.md sammenlignet med CLAUDE.md, .cursorrules og copilot-instructions.md

Forskellen i praksis

De værktøjsspecifikke filer forsvinder ikke, og det er heller ikke meningen, de skal. Forskellen handler om portabilitet over for specialisering. Generelle regler om opsætning, test og sikkerhed hører hjemme i AGENTS.md, fordi flere værktøjer kan læse dem. Regler, der kun giver mening for ét bestemt værktøjs syntaks, kommandoer eller tilstande, hører hjemme i det værktøjs egen fil. Claude Code centrerede sig historisk om CLAUDE.md og importerede AGENTS.md, men er ifølge en rapport fra september 2026 begyndt at læse AGENTS.md nativt fra version 2.1.277, udgivet 18. september 2026. Cursor har på samme måde gjort .cursorrules til en legacy-konvention til fordel for .cursor/rules/*.mdc, mens AGENTS.md fortsat læses ved siden af.

Har projektet allerede en CLAUDE.md, en .cursorrules eller en copilot-instructions.md, behøver du ikke skrive alt om fra bunden. Gennemgå den eksisterende fil, og flyt de dele, der ikke er specifikke for netop det ene værktøj, over i en ny AGENTS.md. Behold kun det værktøjsspecifikke tilbage i originalfilen, og erstat gerne det, der er flyttet, med en kort henvisning til AGENTS.md, så de to filer ikke risikerer at drive fra hinanden over tid.

Fil	Tilhører	Rolle
AGENTS.md	Alle understøttede værktøjer	Portable, fælles regler for opsætning, test, stil og sikkerhed
CLAUDE.md	Claude Code	Claude-specifik adfærd og imports, understøtter nu også AGENTS.md nativt
.cursorrules	Cursor (legacy)	Ældre konvention, erstattes gradvist af .cursor/rules/*.mdc
.github/copilot-instructions.md	GitHub Copilot	Repo-specifikke instruktioner til Copilots coding agent og GitHub-workflows

Hvilke værktøjer understøtter AGENTS.md i dag

Ifølge en gennemgang fra 22. september 2026 lister det officielle AGENTS.md-websted 24 kompatible værktøjer. Understøttelsen varierer dog i modenhed, og et par værktøjer, blandt andet Googles Gemini CLI, har konkurrerende rapporter om, hvorvidt AGENTS.md læses nativt, eller om filen skal konfigureres separat ved siden af værktøjets eget GEMINI.md-format. Tabellen nedenfor opsummerer status, som den er rapporteret i september 2026. Behandl den som et øjebliksbillede, ikke en garanti, tjek altid det konkrete værktøjs egen dokumentation, før du lægger en kritisk arbejdsgang an på, at det læser AGENTS.md på en bestemt måde, især for værktøjer med hyppige versionsopdateringer.

Værktøj	Status	Note
OpenAI Codex (CLI, IDE-udvidelse, app)	Nativ	En af formatets oprindelige bidragydere
GitHub Copilot coding agent	Nativ	Kan suppleres med .github/copilot-instructions.md
Cursor	Nativ	.cursorrules er nu legacy til fordel for .cursor/rules
Amp (Sourcegraph)	Nativ	Adopterede formatet omkring august 2025
Google Jules	Nativ	En af formatets oprindelige bidragydere
Claude Code	Nativ fra v2.1.277	Rapporteret 18. september 2026, historisk centreret om CLAUDE.md
Gemini CLI	Delvis / konfigurerbar	Nativ fil er GEMINI.md, kilder er uenige om AGENTS.md-understøttelse
Windsurf, Aider, Zed, Devin, Factory, Warp, JetBrains Junie	Nativ	Listet i flere uafhængige værktøjsoversigter fra 2026

5 almindelige faldgruber

De fleste problemer med AGENTS.md opstår ikke, fordi formatet er kompliceret, men fordi teamet behandler det, som om det var mere formelt, end det er. Her er de fem faldgruber, der går igen oftest:

• At behandle AGENTS.md som en formel specifikation. Det er en Markdown-konvention, ikke et skema med garanteret adfærd. Understøttede sektioner, arvefølge og størrelsesgrænser varierer fra værktøj til værktøj.
• At antage, alle værktøjer opfører sig ens. Claude Code og Gemini CLI er begge eksempler på værktøjer, hvor understøttelsen har ændret sig i løbet af 2026, så tjek dokumentationen, før du stoler blindt på nativ læsning.
• At skrive en alt for lang fil. En omfangsrig instruktionsmanual fortynder de vigtige kommandoer, og øger risikoen for, at agenten overser eller fejlfortolker dem.
• At have modstridende regler i flere filer. Hvis AGENTS.md siger én ting, og CLAUDE.md eller .cursor/rules siger noget andet, får du værktøjsafhængig adfærd, som er svær at fejlfinde.
• At lade kommandoerne blive forældede. En instruktion, der peger på et script, der ikke længere findes, er værre end slet ingen instruktion, fordi agenten forsøger at følge den og fejler uden kontekst.

Fejlfinding: 8 problemer og deres løsninger

Selv en velskrevet AGENTS.md støder på problemer, typisk fordi et værktøj er opdateret, eller fordi filen ikke er fulgt med, da projektet ændrede sig. Tabellen herunder samler de otte mest almindelige symptomer, teams rapporterer, sammen med den mest sandsynlige årsag og en konkret løsning:

Symptom	Sandsynlig årsag	Løsning
Agenten ignorerer testkommandoen	Kommandoen står i prosa, ikke i et kodeblok	Skriv den som en eksakt, kørbar kommando under Testing
Claude Code læser kun CLAUDE.md	For gammel version af klienten	Opdatér til v2.1.277 eller nyere for nativ AGENTS.md-støtte
Cursor følger reglerne inkonsekvent	Modstridende regler i .cursor/rules og AGENTS.md	Konsolidér reglerne, og lad .cursor/rules referere til AGENTS.md
Agenten redigerer genererede filer	Genererede mapper er ikke nævnt under Overview	List eksplicit, hvilke mapper der er auto-genererede
Nested AGENTS.md bliver ignoreret	Værktøjet understøtter ikke hierarkiet, eller filnavnet har forkert case	Tjek værktøjets dokumentation for arvefølge, og ret filnavnets case
CI fejler efter en agent-commit	Lint-kommandoen mangler i AGENTS.md	Tilføj den eksplicitte lint-kommando under Testing
Agenten foreslår at fjerne sikkerhedstjek	Manglende eller uklart sikkerhedsafsnit	Skriv eksplicitte forbud i Security-sektionen
To værktøjer opfører sig forskelligt på samme repo	Forskellig understøttelsesmodenhed mellem værktøjerne	Tjek værktøjstabellen, og hold værktøjsversioner opdaterede på tværs af teamet

Fælles for stort set alle otte er, at løsningen sjældent kræver at omskrive hele filen. Det handler typisk om at rette én sektion, opdatere én kommando eller fjerne én modsigelse mellem to filer, hvilket er en del af grunden til, at formatet er nemt at vedligeholde, når først grundstrukturen er på plads.

Avancerede tips til teams og monorepos

• Brug nestede AGENTS.md-filer pr. pakke i stedet for én kæmpe rodfil, hvis repoet dækker flere services med forskellige testkommandoer.
• Lad .cursor/rules, .github/copilot-instructions.md og CLAUDE.md importere eller henvise til AGENTS.md, i stedet for at duplikere de samme regler flere steder.
• Brug AGENTS.override.md, hvor Codex understøtter det, til midlertidige regler under en større migrering, og fjern filen, når migreringen er afsluttet.
• Skriv eksempelkommandoer med de faktiske flag, projektet bruger, for eksempel npm test — –runInBand, i stedet for en generisk beskrivelse som “kør testene”.
• Behandl AGENTS.md som kildekode. Læg den i version control, og gennemgå ændringer i code review ligesom enhver anden fil.
• Kør CI-tjekket fra trin 13 på en fast tidsplan, ikke kun ved pull requests, så en forældet kommando bliver opdaget, før en agent løber ind i den.

Rul AGENTS.md ud i et eksisterende team

At tilføje AGENTS.md til et helt nyt projekt tager en halv time. At rulle den ud i et eksisterende team med flere repositories og flere foretrukne værktøjer kræver lidt mere planlægning. Start med ét repository, gerne det, teamet arbejder mest i til daglig, i stedet for at forsøge at dække hele organisationen på én gang. Bed to eller tre udviklere, der bruger forskellige AI-værktøjer, om at teste den samme fil i en uge, og saml deres observationer, før filen bliver skabelon for resten af organisationen.

Undervejs støder de fleste teams på det samme spørgsmål: hvem ejer filen? Svaret, der fungerer bedst i praksis, er at behandle AGENTS.md som en del af projektets almindelige kodebase, ejet af det team, der ejer koden, og vedligeholdt gennem almindelig pull request-review, ikke af en central platformsafdeling, der ikke selv arbejder i repoet. Det holder filen tættere på virkeligheden, fordi de, der først opdager en forældet kommando, også er dem, der kan rette den med det samme.

Har organisationen mange repositories med meget ens opsætning, for eksempel samme sprog og samme testframework på tværs af flere mikroservices, kan det være fristende at lave én skabelonfil og kopiere den ud overalt. Gør det, men tilpas kommandoerne til hvert repo, før filen committes. En kopieret kommando, der ikke passer til det specifikke projekt, skaber præcis den type forældet instruktion, der undergraver tilliden til hele filen.

Mål effekten konkret, i stedet for at basere jer på en fornemmelse. Tæl, hvor mange gange om ugen en agent foreslår en ændring, der bryder en regel, teamet allerede har skrevet ned et sted. Falder det tal efter et par uger med AGENTS.md, virker filen. Ligger det stille, er det som regel et tegn på, at reglerne enten er for vage, eller at de ligger i en sektion, agenten reelt ikke læser, for eksempel fordi den er begravet for langt nede i en for lang fil.

Komplet eksempelprojekt: den fulde fil

Herunder er en samlet AGENTS.md til et lille Node.js/Express-API med en Postgres-database. Du kan kopiere filen direkte ind i roden af et tilsvarende projekt og justere kommandoerne til din egen stack:

# AGENTS.md

## Overview
Node.js/Express REST API til ordrehåndtering.
Kildekode i src/, tests i tests/, migrationer i db/migrations/.
db/generated/ er auto-genereret og må ikke redigeres manuelt.

## Setup
npm install
cp .env.example .env
npm run db:migrate
npm run db:seed

## Development workflow
docker compose up -d postgres
npm run dev

## Testing
npm test -- --runInBand
npm run lint
npm run typecheck

## Code style
Følg .eslintrc og .prettierrc, kør ikke manuel formatering.
Nye endpoints placeres i src/routes/, ét modul pr. ressource.

## Change guidelines
Bryd ikke det offentlige API-kontraktskema i src/schemas/ uden en
separat migrationsplan. Databaseændringer kræver en ny fil i
db/migrations/, aldrig manuel redigering af eksisterende migrationer.

## Pull requests
Alle kommandoer under Testing skal være grønne før PR åbnes.
Commit-beskeder følger Conventional Commits.
Beskriv hvorfor ændringen er lavet, ikke kun hvad der blev ændret.

## Security
Commit aldrig hemmeligheder, tokens eller .env-filer.
Svæk aldrig autentificering for at få en test til at bestå.
Behandl al ekstern input som utroværdigt indtil valideret.

## Definition of done
Tests, lint og typecheck kører grønt.
Dokumentation i docs/ er opdateret, hvis adfærd er ændret.
Ingen nye advarsler i build-output.

Læg mærke til, hvor lidt prosa filen faktisk indeholder. De fleste linjer er enten en kommando eller en konkret regel, hvilket er præcis det, en agent kan handle på uden at gætte. Vil du gå videre, kan du tilføje en tilsvarende, kortere AGENTS.md i en undermappe, hvis projektet vokser til et monorepo, eller krydshenvise til jeres MCP-serveropsætning, hvis agenterne også henter kontekst fra eksterne datakilder. Kører I agenter i isolerede miljøer, er det desuden værd at sammenholde filen med jeres opsætning af dev containers, så setup-kommandoerne i AGENTS.md matcher det miljø, agenten rent faktisk kører i.

Filen er bevidst kort. Det er ikke, fordi eksemplet er forsimplet, men fordi en velskrevet AGENTS.md sjældent behøver at være lang. De ti-tolv linjer under Testing og Security gør mere for agentens adfærd end tre siders generel prosa ville have gjort, netop fordi hver linje er en instruktion, agenten kan handle direkte på.

Ofte stillede spørgsmål

Hvad er AGENTS.md helt konkret?
Det er en almindelig Markdown-fil i roden af et repository, der beskriver opsætning, test, kodestil og sikkerhedsregler for AI-kodeagenter. Den kræver ikke frontmatter eller et fast skema, kun struktureret, konkret indhold.

Skal jeg slette CLAUDE.md eller .cursorrules, når jeg tilføjer AGENTS.md?
Nej. Behold værktøjsspecifikke filer til adfærd, der kun giver mening for netop det værktøj, men flyt generelle regler om opsætning, test og sikkerhed over i AGENTS.md, og lad de andre filer referere til den i stedet for at duplikere reglerne.

Hvor mange værktøjer understøtter AGENTS.md i dag?
Det officielle websted listede 24 kompatible værktøjer ifølge en gennemgang fra september 2026, heriblandt Codex, Cursor, Copilots coding agent, Amp, Jules og Claude Code fra version 2.1.277. Listen vokser løbende, så tjek agents.md direkte, hvis du bruger et værktøj, der ikke er nævnt i denne guide.

Kan AGENTS.md indeholde hemmeligheder eller adgangsnøgler?
Nej. Filen bliver normalt committet til repositoriet og er synlig for alle med adgang. Skriv regler om, hvordan hemmeligheder håndteres, aldrig selve hemmelighederne.

Hvad sker der, hvis jeg har flere AGENTS.md-filer i samme repo?
De fleste værktøjer lader en nestet fil tættere på den redigerede kode supplere eller overskrive rodfilens regler for netop den mappe, men den præcise arvefølge er værktøjsspecifik, så tjek dokumentationen for det værktøj, teamet bruger.

Er der en officiel størrelsesgrænse på filen?
Selve formatet sætter ingen grænse, men OpenAI Codex’ dokumentation nævner en grænse på 32 KiB for instruktionsfiler. Hold filen kortere end det, og opdel i nestede filer, hvis indholdet vokser.

Hvordan holder jeg AGENTS.md opdateret over tid?
Behandl filen som kildekode. Læg et CI-tjek ind, der kører kommandoerne fra filen ved hver pull request, som beskrevet i trin 13, så en forældet kommando bliver fanget automatisk.

Virker AGENTS.md uden internetforbindelse, eller kræver den et specifikt værktøj?
Filen er bare Markdown og kræver ingen internetforbindelse i sig selv. Det er det enkelte AI-værktøj, ikke filen, der afgør, om det kan læse og handle på indholdet lokalt eller kun i skyen.

Skal en solo-udvikler også bruge AGENTS.md, eller er det kun relevant for teams?
Det giver værdi selv i et enkeltmandsprojekt, fordi den samme udvikler ofte skifter mellem flere AI-værktøjer i løbet af en uge. En fælles fil betyder, at man ikke selv skal huske at fortælle hvert værktøj det samme igen og igen, og den fungerer samtidig som dokumentation, hvis andre senere overtager projektet.