# Sådan konfigurerer du CLAUDE.md i 2026: Skabelon og 6 regler > En klar CLAUDE.md-skabelon, 6 regler til at holde filen levende og en analyse af en fil, der bruges i en aktiv virksomhed. Indeholder officielle citater fra Anthropic. Source: https://ailoot.ai/blog/da/claude-md-template/ Canonical: https://ailoot.ai/blog/da/claude-md-template/ Language: da Publisher: Ailoot (https://ailoot.ai/) Translation: guide-126 Revision: sha256-b6abefca1339f3fdc4050b59d2add5ca10c30e6dd05b97d6cce4098841071216
Det vigtigste CLAUDE.md er en tekstfil i roden af et projekt, som Claude Code læser i begyndelsen af hver session. Uden den starter agenten fra bunden hver gang: Du bruger 5-10 minutter på at sige: “Hej, jeg arbejder på dette projekt, det her er min målgruppe, og sådan er min stil.” En kompakt startfil sigter ofte efter 100-200 linjer; det er en retningslinje for gennemgang, ikke et teknisk loft. Skabelonen indeholder 6 afsnit (beskrivelse, værktøjer, struktur, filhenvisninger, regler og sprog) og opdateres, hver gang Claude begår en fejl. Artiklen indeholder en skabelon, der er klar til brug, 6 regler, en analyse af en fil, der bruges i en aktiv virksomhed, og en tjekliste til gennemgang med 12 punkter.
Materiale om vibe coding: værktøjer, casestudier, fejl. [Ailoot Guides](https://ailoot.ai/docs/).
[Ailoot Guides](https://ailoot.ai/docs/)
## Hvorfor har du brug for CLAUDE.md, og hvorfor glemmer Claude projektet uden den?
Det vigtigste I Claude Code starter hver ny chat med en tom kontekst. CLAUDE.md er den eneste fil, som Claude automatisk indlæser i hver ny session. Uden den arbejder agenten som en praktikant på sin første dag: Den ved intet om din virksomhed, din stil eller dine regler. Med den arbejder den som en medarbejder på sit andet år.
Du åbner Claude Code tirsdag og forklarer: “Jeg arbejder på dette projekt, det her er værktøjerne, gør ikke sådan.” Det virker. Torsdag er den samme chat allerede afsluttet, så du gentager alt. Lørdag igen; mandag endnu en gang. Sådan ser det ud at arbejde med en agent uden CLAUDE.md: Hvert nyt vindue er en praktikant, der starter med blanke ark, og som du må fortælle de samme ting igen og igen. Jeg plejede at bruge 5-10 minutter på at skrive denne opvarmning til hver session. Promptene blev lange, fordi jeg selv skulle medbringe al konteksten. Og resultatet var stadig generisk: Agenten kendte ikke min målgruppe, min økonomi eller mine principper.
Bemærk Det er ikke et problem med modellens hukommelse. Det skyldes arkitekturen. Claude Code starter bevidst med en ren kontekst i hver session; ellers ville forskellige projekter på samme computer blive blandet sammen. CLAUDE.md er mekanismen, der lader dig fortælle agenten, hvad den skal indlæse.
Med en levende CLAUDE.md forsvinder opvarmningen. Alle de regler, du plejede at gentage i hver chat, står i én fil og vises automatisk i begyndelsen af hver session. Prompten bliver kort: “gør X” i stedet for “jeg arbejder på projekt Y, værktøjerne er Z, gør ikke A eller B, og husk for resten også C.” Så forsvinder de tilbagevendende fejl. Hver agentfejl er en grund til at tilføje en linje til CLAUDE.md. Efter en måned har du en levende “projektforfatning”, og Claude holder op med at falde i de samme velkendte fælder. Og så er der et tredje lag: Agenten holder op med at skrive i et vakuum. Via `CLAUDE.md` henviser jeg Claude til mapper med kontekst: hvor den skal lede efter oplysninger om målgruppen, priserne og brandingen. Uden disse henvisninger skriver agenten “løsninger af høj kvalitet” uden at kende min økonomi, så de bliver abstrakte, skabelonagtige og “lige som alle andres”. ## Hvad er CLAUDE.md, og i hvilken rækkefølge læser Claude den?
Det vigtigste CLAUDE.md er en tekstfil i Markdown-format. Claude Code leder efter den fire steder på én gang: på systemniveau, brugerniveau, i projektroden og i lokale noter. Alle fire indlæses i konteksten i begyndelsen af hver session. Filnavnet skelner mellem store og små bogstaver: Brug altid `CLAUDE.md` med store bogstaver.
Anthropic beskriver CLAUDE.md sådan i sin officielle dokumentation:
CLAUDE.md-filer er Markdown-filer, der giver Claude vedvarende instruktioner til dit projekt, din personlige arbejdsgang eller hele din organisation. Du skriver dem i almindelig tekst, og Claude læser dem i begyndelsen af hver session.
— Anthropic, code.claude.com/docs/en/memory
De fire steder, hvor Claude Code leder efter CLAUDE.md, i stigende prioritetsrækkefølge: | Niveau | Placering | Formål | |----|----|----| | **Organisation** | `/Library/Application Support/ClaudeCode/CLAUDE.md` på Mac, `/etc/claude-code/CLAUDE.md` på Linux | Regler, som virksomhedens administrator ruller ud til hele teamet via MDM. Du har ikke brug for dette som enkeltperson. | | **Bruger** | `~/.claude/CLAUDE.md` | Personlige regler, der gælder på tværs af alle dine projekter. “Svar altid på brugerens foretrukne sprog”, “brug ikke em dash-tegn.” | | **Projekt** | `./CLAUDE.md` i projektroden eller `./.claude/CLAUDE.md` | Regler for et bestemt projekt: værktøjer, mappestruktur, forretningslogik. Denne fil checkes ind i git. | | **Lokal** | `./CLAUDE.local.md` | Dine personlige noter til projektet, som ikke skal med i git. For eksempel midlertidige eksperimenter eller personlige præferencer, som teamet ikke behøver at kende til. | Alle fire filer indlæses i konteksten på samme tid. Hvis reglerne er i konflikt, siger Anthropic direkte i dokumentationen, at det er ukendt, hvilken der får forrang; Claude kan vælge en af dem vilkårligt. Derfor er det enklere at samle alt kritisk i projektets CLAUDE.md og undgå dubletter.
Tip Filnavnet skelner strengt mellem store og små bogstaver. Brug `CLAUDE.md` med store bogstaver, så læser Claude den. Den læser ikke `claude.md` eller `Claude.md`. Det samme gælder `CLAUDE.local.md`. Det er en typisk fejl blandt folk, der konfigurerer Claude Code for første gang: De opretter en fil, skriver instruktionerne, undrer sig over, at det ikke virker, og opdager så, at filnavnet er skrevet med små bogstaver.
Der er en teknisk detalje, som næsten ingen skriver om, men som forklarer en del mærkelig adfærd.
Indholdet af CLAUDE.md sendes som en brugermeddelelse efter systemprompten, ikke som en del af systemprompten. Claude læser den og forsøger at følge den, men der er ingen garanti for, at instruktionerne følges nøje.
— Anthropic, code.claude.com/docs/en/memory
Med andre ord er CLAUDE.md ikke en “systemprompt” i streng forstand. Det er den første brugermeddelelse, Claude ser. Dens regler er altså stærke anbefalinger, ikke love. Hvis en regel skal håndhæves, skal du bruge en testet hook til den dækkede hændelse og tilladelser eller miljøisolering til den bredere adgangsgrænse. At en hook køres automatisk gør ikke dens kontroller fuldstændige. Jeg forklarer grænsen mellem `hooks` og `CLAUDE.md` nedenfor. ## Hvordan skriver du en minimal CLAUDE.md på 5 minutter (skabelon, der er klar til brug)?
Det vigtigste Kopiér skabelonen, erstat felterne i kantede parenteser, og gem den i projektroden som `CLAUDE.md`. Det er nok til at forhindre Claude i at starte fra bunden i hver session. Du kan udvide den undervejs med reglen: “Tilføj en linje efter hver agentfejl.”
Nedenfor er en skabelon, jeg har testet på dusinvis af mine projekter. Den holder filen på omkring 80-120 linjer, inden for Anthropics anbefaling om at sigte efter under 200 linjer. Med denne skabelon giver agenten de mest fornuftige resultater. ```markdown # [PROJECT NAME] - project navigation This document is the project map. Read it at the start of every session to understand where things are and how to work with them. ## What this project is **[NAME]** - [one sentence: what it is and who it’s for]. [1-2 sentences: what problem it solves and how]. Details are in `business/INDEX.md`. ## Reading order at the start of every session 1. `about-me/INDEX.md` - who I am and how I think 2. `business/INDEX.md` - what we do (product, audience, economics) 3. `CLAUDE.md` (this file) - repo rules, tools, navigation 4. Task area: the relevant file from `business/`, `plans/`, `mastery/` or the feature folder in the code Principle: layer 1 (about me) comes before layer 2 (business) for a reason. First, **who** is thinking, then **about what**. ## Repository structure [NAME]/ ├── CLAUDE.md ← this file, navigation ├── about-me/ ← digital projection of you (how you think, what you value) │ └── INDEX.md ├── business/ ← the business’s second brain │ ├── INDEX.md │ ├── audience/ ← customer profile │ ├── products/ ← products, prices │ ├── goals/ ← goals, metrics │ └── economics/ ← unit economics, revenue ├── plans/ ← technical plans (one plan = one feature) ├── retrospectives/ ← reflections after each session └── (project code) ### Where to find things | What you need | Where to look | |---|---| | Why we’re building the project, and for whom | `business/INDEX.md` | | Target customer, pains, desires | `business/audience/` | | Product, plans, prices | `business/products/` | | Goals and metrics | `business/goals/` | | Economics | `business/economics/` | | Technical plans | `plans/` | ## Tools [INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL]. ## Repo rules 1. Never hardcode dynamic data (prices, dates, figures) - get everything from files in `business/` and the LIVE marker. 2. Don’t publish without my explicit command. 3. Before `git push`, run `npm run build` and check that it builds without errors or warnings. 4. Add files by name with `git add`. Never use `git add .` or `git add -A`. 5. Don’t read `.env` in full. To check a variable, use `grep "^VAR=" .env`. ## Big features = a plan in `plans/` Any task lasting more than an hour must be written up as a plan in the `plans/` folder: 1. Filename: `YYYY-MM-DD-feature-name.md`. 2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`. 3. At the end of the plan, add a summary: whether it was fully implemented and what remains. ## End-of-feature cycle After each feature is complete, go through these 5 steps: 1. Find errors → prove them with an example → fix them. 2. What was missed (edge cases, input validation, error handling). 3. Is this a real problem in our project? Check `business/` and `plans/`. 4. Take a fresh look: reread the diff as if you’re seeing it for the first time. 5. Security review. Especially: personal data and third-party materials. ## End-of-session reflection In `retrospectives/YYYY-MM-DD_short-name.md`, record: 1. What the task was. 2. How it was solved. 3. Whether it was solved - yes / no / partially. 4. What could have been done better. 5. What was learned about the user or project. ## Language Always respond in the user’s preferred language. Use hyphens only, not em dashes. ``` Hvis du vil have Claude til automatisk at udfylde denne skabelon for dit projekt, så giv den denne prompt. Den læser konteksten og udfylder felterne i kantede parenteser:
Prompt: Udfyld CLAUDE.md for mit projekt ``` Opret en CLAUDE.md-fil i projektets rod ved hjælp af denne skabelon: [INDSÆT HELE SKABELONEN FRA OVENFOR] Fortsæt sådan: Læs about-me/INDEX.md og business/INDEX.md for at forstå projektets kontekst og mig som forfatter. Udfyld alle felterne i kantede parenteser i skabelonen ud fra det, du finder i de mapper. Hvis der mangler oplysninger, så stil mig afklarende spørgsmål ét ad gangen med 3-4 svarmuligheder. Sigt efter at holde den resulterende CLAUDE.md under 200 linjer. Hvis den er længere, skal du gennemgå dubletter og flytte detaljerede procedurer til tilknyttede filer. Bevar væsentlige regler om planlægning, refleksion og repoet, og test dem derefter på repræsentative opgaver. Vis mig den endelige fil, og spørg, hvad der skal revideres. Svar altid på brugerens foretrukne sprog. ```
Hvis du endnu ikke har mapperne `about-me/` og `business/`, er det helt i orden. Claude vil stille afklarende spørgsmål og samle en minimal CLAUDE.md ud fra det, der er tilgængeligt. Du kan oprette mapperne senere, når du ved, hvad du skal lægge i dem. ## Hvilke 6 regler gør CLAUDE.md til et levende dokument?
Det vigtigste Disse 6 regler er en sammenfatning af erfaringer fra dusinvis af projekter. De gør CLAUDE.md til et arbejdsdokument, som Claude bruger i hver session, i stedet for “en fil, vi oprettede og glemte”.
### Regel 1. Hold den under 200 linjer Anthropic siger det kort og præcist i sin officielle dokumentation:
Sigt efter at holde CLAUDE.md under 200 linjer. Længere filer bruger mere kontekst og mindsker, hvor godt instruktionerne følges.
— Anthropic, code.claude.com/docs/en/memory
En lang CLAUDE.md modarbejder sig selv på to måder. For det første bruger den tokens. En instruktionsfil på 800 linjer indlæses i hvert vindue og bruger flere tusinde tokens af din kvote i hver session. Med et Pro-abonnement og en daglig grænse reducerer det mærkbart antallet af tilgængelige sessioner. For det andet begynder modellen at ignorere reglerne. Dokumentationen anbefaler at sigte efter under 200 linjer for at mindske kontekstforbrug og forbedre efterlevelsen. Den fastslår ikke en skarp fejlgrænse ved linje 201. Gennemgå relevans, modstridende regler, indlæst tokenmængde og faktiske opgaveresultater, før du beslutter, hvad der skal flyttes ud.
Advarsel Hvis du allerede er nået op på 300-500 linjer, skal du ikke gå i panik - fordel indholdet på flere mapper. Læg detaljerede regler om for eksempel designsystemet i `business/assets/brand-guidelines.md`. CLAUDE.md kan så henvise til den med én linje: “Når du arbejder med brugergrænsefladen, skal du læse `business/assets/brand-guidelines.md`.” Henvisningsprincippet: CLAUDE.md er en indholdsfortegnelse, ikke en bog.
### Regel 2. Afslut hver session med en refleksion Skriv i CLAUDE.md: “I slutningen af hver session skal du notere, hvad du gjorde og lærte, i `retrospectives/YYYY-MM-DD_*.md`.” Når du har tilføjet denne linje, begynder Claude selv at afslutte hver session med en refleksion; du behøver ikke at bede om det. Hvorfor reflektere: - To uger senere kan du åbne en gammel retrospektiv og huske, hvorfor du valgte den vej. - Når du vender tilbage til projektet en måned senere, har du et færdigt overblik over de seneste beslutninger. - Hvis du arbejder i et team, kan en kollega læse den retrospektive og forstå den aktuelle status på 2 minutter uden et møde. ### Regel 3. Commit efter hver afsluttet opgave I min CLAUDE.md står der: “Opret et git-commit med en sigende besked efter hver afsluttet opgave.” Claude begynder selv at opdele arbejdet i atomare commits. Det giver dig to ting. For det første kan du rulle én handling tilbage, hvis noget går galt, i stedet for “alt det, jeg gjorde i dag”. For det andet bliver commit-historikken en arbejdsliste, der viser, hvad der blev ændret og i hvilken rækkefølge. ### Regel 4. Slå altid op i mappen `business/` Ved enhver opgave, der involverer kunder, produkter eller tekst, bør agenten først åbne `business/INDEX.md` og den relevante fil derfra. Min CLAUDE.md siger udtrykkeligt: “Når du arbejder med brugergrænsefladen eller tekst, skal du først tjekke `business/audience/avatar.md` og `business/assets/brand-guidelines.md`.” Uden denne regel skriver Claude tekst i “den generelle stil fra en kvalitetswebside”. Med den skriver den i din stil, til din kunde og uden dine forbudte ord. ### Regel 5. Tilføj en regel efter hver agentfejl Det er hovedreglen, der holder CLAUDE.md levende. Eksempler fra min egen CLAUDE.md, som blev tilføjet efter konkrete fejl: - “Check aldrig andres WIP-filer ind med `git add .` - stage filer med navn.” - “Tjek `git log origin/main..main --oneline`, før du pusher til `main` - hvis resultatet ikke er tomt, så lad være med at pushe.” - “Find ikke på værdier - hent dem fra `.env` eller koden. Især URL'er, brugernavne og tokens.” Hver af disse linjer er et spor efter en bestemt hændelse. En gang checkede en agent en partners ufærdige branch ind. En anden gang inkluderede jeg andres commits, som ikke var pushet. En tredje gang fandt en agent på en URL, der ikke findes. Hver fejl bliver til en regel, så den samme selvforskyldte skade ikke sker igen. ### Regel 6. Læg sikkerheden i `.claude/settings.json`, ikke i CLAUDE.md I CLAUDE.md kan du skrive “rør ikke `.env`”, men det er en anmodning; Claude kan overtræde den, fordi CLAUDE.md indlæses som en brugermeddelelse, ikke som en lov. Til kritisk sikkerhed skal du bruge `.claude/settings.json`, hvor du kan blokere bestemte kommandoer fuldstændigt. Den blokeringsliste, jeg tilføjer til hvert nyt projekt: - `rm -rf` (rekursiv sletning af filer). - Fuld læsning af `.env` (`Read .env`). - `export` og `curl` i samme kommando (et mønster til at lække hemmeligheder eksternt). - `git push --force` uden udtrykkelig godkendelse.
Advarsel Forskellen er enkel: En regel i CLAUDE.md er et råd, som agenten kan overtræde. En matchende deny-regel blokerer den dækkede handling i den relevante tilladelsesgang. Det er ikke bevis mod enhver tilsvarende kommando, et andet værktøj eller en anden tilladelsestilstand. Læg kritiske sikkerhedsregler i `settings.json` og alt andet i CLAUDE.md.
Find flere vejledninger på [Ailoot](https://ailoot.ai/docs/).
[Ailoot Guides](https://ailoot.ai/docs/)
## Hvordan er CLAUDE.md struktureret i en aktiv virksomhed (anatomi af en fil på 280 linjer)?
Det vigtigste Jeg gennemgår strukturen i en CLAUDE.md-fil, der bruges af en aktiv onlinetjeneste. Filen er cirka 280 linjer lang og har 11 afsnit. Jeg viser, hvad hvert afsnit indeholder, og hvorfor. Jeg offentliggør ikke selve teksten; den indeholder driftsoplysninger. Men strukturen kan bruges i enhver virksomhed.
De fleste eksempler på CLAUDE.md online er tekniske skabeloner til udviklere: “Brug TypeScript”, “Skriv ikke tests, der er længere end 50 linjer.” For en iværksætter er den slags CLAUDE.md ubrugelig - den dækker ikke forretningssiden. Nedenfor er strukturen i min CLAUDE.md, som jeg bruger i praksis. Jeg har fjernet de konkrete regler og stier, fordi de afspejler min interne drift. Men afsnittenes struktur og logik kan bruges i ethvert projekt: Sæt dine egne forhold ind, så får du en fil, der fungerer. **1. Kort projektbeskrivelse (15 linjer).** Hvad vi laver, hvem målgruppen er, og hvilke produkter vi tilbyder. Ikke en gennemgang af marketingwebsitet, men en opsummering til agenten, så den forstår “hvor vi er på vej hen”. **2. Om mig (10 linjer).** En henvisning til mappen `about-me/` - en digital afspejling af, hvordan jeg tænker. Tone, værdier, principper og forbudte ord. Når Claude skriver tekst “som mig”, læser den denne mappe først, så stemmen passer. **3. Repository-struktur (20 linjer).** Et træ med kommentarer: hvor koden er, hvor forretningskonteksten ligger, og hvor planer og retrospektiver findes. Uden dette kort søger Claude blindt efter filer hver gang. **4. Tabellen “Hvor finder man ting” (25 linjer).** Henvisninger fra “spørgsmål → fil”. For eksempel kunne der for et ejendomsmæglerfirma stå “brug for lånevilkår → `business/products/mortgage.md`” eller “brug for tone of voice til opslag → `business/assets/voice.md`”. Erstat eksemplerne med dine egne filer. Denne tabel er kernen i CLAUDE.md. Uden den gætter agenten på, hvilken fil der indeholder svaret. Med den går den direkte til kilden. **5. Vigtige projektprincipper (40 linjer, 10-15 punkter).** Dette afsnit vokser langsomt og kræver mest arbejde. Hvert punkt er sporet af en konkret fejl. For en netbutik kunne reglerne for eksempel være “hardcod aldrig priser og leveringstider”, “publicér ikke et produkt uden en udtrykkelig kommando” og “kontrollér stilen mod brandordlisten, før du publicerer en produktbeskrivelse”. Dette afsnit er “projektforfatningen”. **6. Driftsplanlægning (20 linjer).** En tabel med udløsere, der forbinder “brugerens formulering → handling”. For eksempel: “Når jeg siger ‘planlæg ugen’, så åbn `ops/monthly.md` og opret ugens fil.” Det gør Claude til en driftsassistent, der forstår sammenhængen i kommandoer. **7. Værktøjer (5 linjer).** Teknologier. Kort og uden fyld. **8. Publicering (15 linjer).** En trinvis proces til at publicere ændringer til produktion: hvilke kommandoer der skal køres, i hvilken rækkefølge, og hvad der skal kontrolleres. Jeg plejede at forklare det hver gang. Nu ved Claude det. **9-12. Sikkerhed (35 linjer).** Fire separate underafsnit: regler for håndtering af `.env`, adgang til produktionsdatabasen, sikre kommandoer til demoer (skærmoptagelser, streams, skærmbilleder, så tokens ikke ved et uheld bliver eksponeret) og regler for rotation af hemmeligheder. **13. Mappen `plans/` (10 linjer).** Planstandarden: filnavn, fasestruktur og hvad der skal stå i opsummeringsblokken. **14. Mappen `retrospectives/` (5 linjer).** Refleksionsstandarden: skabelon, filnavn og hvad den skal indeholde. **15. Aktuelle databasedata (15 linjer).** En regel om at markere “friske data”: Når en fil siger, at tal skal være aktuelle, henter agenten dem fra kilden i stedet for at bruge gamle tal. Det fjerner risikoen for, at Claude bruger gårsdagens tal. **16. Sprog (3 linjer).** “Svar altid på brugerens foretrukne sprog. Brug kun bindestreger, ikke em dash-tegn.” Cirka 280 linjer i alt. Det overskrider målet for kompakthed, men gør ikke filen ugyldig. I dette eksempel var den fortsat nyttig; beslutningen om at beholde den bør afhænge af målt kontekstforbrug og repræsentative opgavekontroller. Tabeller er ikke automatisk billigere i tokens end prosa.
Tip Den struktur, jeg har udviklet gennem et års arbejde, er ikke et dogme. Rammeværket er: beskrivelse (1-2 afsnit), struktur og henvisninger (2-3 afsnit), regler/principper (1 stort afsnit), driftsprocedurer (2-3 afsnit, der er specifikke for din virksomhed) og små detaljer (sprog, kontaktoplysninger). Fyld det med detaljer, der er specifikke for din virksomhed. Hovedreglen: Hvert afsnit skal besvare spørgsmålet “Ville Claude begå en fejl uden dette?” Hvis ikke, så fjern det.
## Hvad gør kommandoen `/init`, og hvorfor er den ikke nok?
Det vigtigste Kommandoen `/init` i Claude Code opretter automatisk en grundlæggende CLAUDE.md ved at scanne projektet og opremse værktøjer og build-kommandoer. Det er et godt udgangspunkt, men uden forretningskontekst og principper bliver filen teknisk og generisk. Brug `/init` som første trin, og byg derefter videre på den i hånden.
Anthropic beskriver kommandoen sådan i sin dokumentation:
Kør /init for automatisk at generere en grundlæggende CLAUDE.md. Claude analyserer din kode og opretter en fil med build-kommandoer, testinstruktioner og registrerede projektkonventioner.
— Anthropic, code.claude.com/docs/en/memory
Det er `/init` god til: - Identificerer værktøjerne ud fra `package.json`, `Cargo.toml` og `pyproject.toml`. - Oplister build- og testkommandoer. - Opfanger konventioner fra eksisterende filer (`.eslintrc`, `.prettierrc`). - Opdager eksisterende Cursor-regler (`.cursorrules`, `.cursor/rules/`) og Copilot-regler og tager relevante dele med. Den indlæser `AGENTS.md` i tilstanden `CLAUDE_CODE_NEW_INIT=1`. Det gør `/init` ikke: - Den ved ikke, hvem din kunde er. - Den medtager ikke dine forbudte ord til tekster. - Den tilføjer ikke regler om agentfejl (for der har ikke været nogen endnu). - Den opretter ikke en tabel over “hvor man finder ting” for din virksomhedsstruktur. Derfor er den rigtige arbejdsgang: 1. ### Kør /init i Claude Code Du får en grundlæggende CLAUDE.md på 30-50 linjer med værktøjer og kommandoer. Det er det tekniske fundament. 2. ### Læg skabelonen fra denne artikel ovenpå Brug afsnittet “En minimal CLAUDE.md på 5 minutter”. Tilføj afsnit om navigation, henvisninger og principper. 3. ### Udfyld felterne i kantede parenteser Giv Claude prompten “læs mit projekt og udfyld skabelonen”. Hvis mapperne `business/` og `about-me/` endnu ikke findes, vil Claude stille afklarende spørgsmål. 4. ### Kør en stresstest Sig til Claude: “Læs min CLAUDE.md, og find 10 uklarheder, der kan få dig til at misforstå som agent.” Du får en liste med forbedringer. 5. ### Brug derefter filen i praksis Tilføj en linje efter hver agentfejl. Efter en måned har du en levende CLAUDE.md, der er tilpasset din virksomhed. Prompt til trin fire:
Prompt: Stresstest CLAUDE.md ``` Jeg har en CLAUDE.md. I morgen skal jeg bygge en funktion ud fra den. Din opgave er at stressteste den. Find 10 grunde til, at vi potentielt kan fejle: hvor CLAUDE.md er tvetydig, så du som agent kan misforstå den hvor der er huller, som ville tvinge dig til at finde på noget hvor regler modsiger hinanden hvor jeg overvurderer, hvor meget der kan nås på én dag hvor jeg undervurderer tingene (det er endnu værre) Læg ikke fingrene imellem. Kritiser den hårdt. Jeg vil finde problemerne nu, ikke i produktion. Til sidst skal du give mig en liste over konkrete ændringer: hvad der skal ændres, og hvordan, så problemerne ikke opstår. ```
## CLAUDE.md sammenlignet med AGENTS.md og MEMORY.md: hvem læser hvad i 2026?
Det vigtigste Tre lignende filer bliver ofte forvekslet. CLAUDE.md indeholder projektrelaterede regler, som du selv skriver, og Claude Code læser i hver session. AGENTS.md er en universel standard for andre agenter (Codex, Cursor, Copilot), og siden september 2026 læser Claude Code den også, hvis projektet ikke har en CLAUDE.md. MEMORY.md indeholder automatiske noter, som Claude skriver til sig selv om dine vaner. Alle tre kan eksistere samtidig uden konflikt.
| Fil | Hvem skriver den | Hvem læser den | Hvornår indlæses den | |----|----|----|----| | **CLAUDE.md** | Dig, manuelt | Claude Code (indbygget) | I begyndelsen af hver session | | **AGENTS.md** | Dig, manuelt | Codex CLI, Cursor, GitHub Copilot CLI, Gemini CLI og siden version 2.1.277 Claude Code, hvis projektet ikke har en CLAUDE.md | I begyndelsen af hver session | | **MEMORY.md** | Claude Code selv | Claude Code (indbygget) | I begyndelsen af hver session, de første 200 linjer (eller 25 KB, alt efter hvad der er mindst) | Det vigtigste spørgsmål, der forvirrer nybegyndere, er: **læser Claude Code `AGENTS.md`?** Før september 2026 var svaret “nej”: Anthropics dokumentation anbefalede at oprette en CLAUDE.md, der importerer AGENTS.md. Siden version 2.1.277 (udgivet 18. september 2026) læser Claude Code selv AGENTS.md, men kun hvis der ikke findes nogen CLAUDE.md, `.claude/CLAUDE.md` eller `CLAUDE.local.md` i arbejdsbiblioteket eller over det.

Claude Code kan læse AGENTS.md som projektinstruktioner, så et repository, der allerede er konfigureret til andre agenter, fungerer uden CLAUDE.md, en import eller konfiguration.

— Anthropic, https://code.claude.com/docs/en/memory#agents-md
Hvis projektet har en CLAUDE.md, læser Claude Code som standard kun den og springer AGENTS.md over. Du kan ændre dette i `/config` under Project instructions: For eksempel får indstillingen `claude-md-and-agents-md` den til at læse begge filer. En anden metode virker i alle versioner: Tilføj en import i CLAUDE.md: ```markdown @AGENTS.md ## Claude Code Additional rules for Claude Code that other agents don’t need. ``` Syntaksen `@filename` importerer en anden fil. Claude læser den og indlæser den i konteksten sammen med CLAUDE.md. Importen får ikke filen til at blive læst to gange, selv hvis Claude Code kan læse AGENTS.md på egen hånd. **Hvornår du har brug for AGENTS.md.** Hvis du arbejder parallelt med Claude Code og Codex CLI, Cursor eller Copilot, skal du oprette en AGENTS.md som den eneste kilde til sandheden, tilføje `@AGENTS.md` i CLAUDE.md og lægge eventuelle Claude-specifikke regler oveni. Hvis der ikke er sådanne regler, behøver du ikke oprette CLAUDE.md: Siden version 2.1.277 læser Claude Code selv AGENTS.md. Hvis du kun arbejder i Claude Code, behøver du ikke AGENTS.md; brug kun én CLAUDE.md. Se [vejledningen til at bruge AGENTS.md og CLAUDE.md i ét projekt](https://ailoot.ai/blog/da/agents-md-claude-md-one-instruction-file/) for en trinvis gennemgang af alle mulighederne. **Hvad er MEMORY.md?** Efter en nyere opdatering gemmer Claude Code automatisk noter om dig i `~/.claude/projects//memory/MEMORY.md`. Det kan være samtalevaner (“brugeren foretrækker korte svar”), tilbagevendende formuleringer (“forbød emojis i kode”) og observationer om adfærd (“arbejder på macOS, bruger zsh”). Det er et separat hukommelsessystem, ikke CLAUDE.md. Du skriver det ikke i hånden; Claude gør det ud fra jeres samtaler. Hvis MEMORY.md indeholder noget, der bør blive til en regel, skal du flytte det til CLAUDE.md. Hvis den indeholder noget unødvendigt eller forkert, kan du slette det manuelt; det er en tekstfil.
Bemærk Skriv `/memory` i Claude Code for at se, hvad der indlæses i begyndelsen af en session. Den viser indholdet af CLAUDE.md, MEMORY.md og andre indlæste filer. Det er nyttigt, når Claude opfører sig mærkeligt: Åbn `/memory`, og se efter den regel, der kan have forårsaget det.
## Hvilken størrelse er nyttig for CLAUDE.md, og hvordan gennemgår du en lang fil?
Det vigtigste Længere instruktionsfiler bruger mere kontekst og kan gøre relevante regler sværere at følge, især med dubletter eller modstridende regler. Anthropic anbefaler at sigte efter under 200 linjer. Anbefalingen er ikke et teknisk loft eller en universel forudsigelse af, hvor mange regler agenten vil følge.
I hvert Claude Code-vindue indlæses flere lag i konteksten: Anthropics systemprompt (anslået til titusindvis af tokens), din CLAUDE.md, filer importeret med `@`, MEMORY.md, den aktuelle chathistorik og indholdet af de filer, Claude åbner. Alt dette skal kunne være i modellens kontekstvindue (200K tokens for Sonnet, 1M for Opus). Jo større CLAUDE.md bliver, desto mindre plads er der til det aktuelle arbejde. En fil på 1.000 linjer er cirka 8.000 tokens og gentages i hver session. Med et Pro-abonnement (efter min erfaring omkring 10-12 “tunge” prompts om dagen) reducerer det din kapacitet med en fjerdedel. Omkostningen er kun ét hensyn. Efterlevelsen kan forringes, når instruktioner er lange, irrelevante eller indbyrdes modstridende; der findes ikke et universelt antal instruktioner, som følges pålideligt. Test nogle repræsentative opgaver, der bruger de kritiske regler, registrér fejl, og sammenlign adfærden efter en målrettet redigering.
Oppustede CLAUDE.md-filer får Claude til at ignorere dine egentlige instruktioner.
— Anthropic, code.claude.com/docs/en/best-practices
Her er derfor tommelfingerreglen for størrelsen: - **80-120 linjer** - et praktisk udgangspunkt for et kort projektkort, ikke en garanti for efterlevelse. - **150-200 linjer** - en nyttig anledning til at gennemgå relevans og flytte detaljerede procedurer til tilknyttede filer. - **200-300 linjer** - undersøg tokenmængde, dubletter og opgaveresultater; virksomhedseksemplet med 280 linjer ovenfor kan stadig fungere godt. - **400+ linjer** - en stærk grund til en målrettet gennemgang, ikke bevis for, at filen er ubrugelig. Bevar væsentlige begrænsninger, og flyt først detaljer efter kontrol af, at links og regler stadig virker. Linjeantal alene kan ikke dokumentere succes eller fiasko. Gentag de samme repræsentative opgaver efter en redigering, og verificér de vigtige regler i stedet for at tildele en opdigtet efterlevelsesprocent.
Advarsel Hvis din CLAUDE.md er vokset sig for stor, skal du ikke omstrukturere den i hånden. Giv Claude denne prompt: “Læs CLAUDE.md, og vurder hver linje ud fra spørgsmålet: ‘Hvis denne linje blev fjernet, ville agenten så begå en fejl?’ Returnér en liste over linjer, der kan fjernes uden tab, med en begrundelse.” Den fjerner det, der objektivt ikke virker.
Anthropic giver en direkte test i sin dokumentation:
Spørg for hver linje: ‘Hvis jeg fjerner den, begynder Claude så at begå fejl?’ Hvis ikke, så slet den.
— Anthropic, code.claude.com/docs/en/best-practices
Brug testen på hver linje. Hvis svaret er “den ville stadig gøre det rigtigt”, så fjern linjen. CLAUDE.md er ikke stedet til dokumentation, beslutningshistorik eller filosofi. Den er kun til de regler, agenten har brug for for at undgå at begå fejl. ## Hvilke 7 fejl gør CLAUDE.md ubrugelig?
Det vigtigste Her er syv almindelige fejl, jeg jævnligt ser i andres CLAUDE.md-filer. Hver af dem er en grund til at rydde metodisk op i filen. De fleste er variationer over ét problem: at forsøge at gøre CLAUDE.md til et universelt “projektdokument” i stedet for at holde den som et arbejdsredskab til agenten.
### Fejl 1. “Vær en god ingeniør” Den mest almindelige fejl. Folk skriver generelle ønsker i CLAUDE.md: “skriv ren kode”, “brug best practices”, “tænk som en senioringeniør”. Disse ord betyder ingenting. Claude skriver allerede “ren kode” i almindelig forstand. Linjerne optager kontekst uden at påvirke nogen beslutning. Erstat “skriv ren kode” med “brug indrykning med 2 mellemrum”, “brug ikke `any` i TypeScript” eller “funktioner må højst være 30 linjer lange”. Konkret og verificerbart. ### Fejl 2. At gentage noget, Claude allerede ved Beskrivelser af almindelige sprogkonventioner (“i JavaScript er funktioner førsteklasses objekter”, “TypeScript har statisk typning”). Forklaringer af, hvordan npm, git eller docker fungerer. Claude lærte alt dette under træningen. At gentage det i CLAUDE.md giver intet; det tager kun plads fra din kontekst. ### Fejl 3. Lange trin-for-trin-instruktioner i CLAUDE.md Lange instruktioner om “hvordan man deployer projektet”, “hvordan man skriver en databasemigrering” eller “hvordan man opsætter en ny komponent”. Dusinvis af trin-for-trin-linjer. Dette er ikke stedet til lange trin-for-trin-instruktioner. Den er til regler på én linje. Læg lange instruktioner i `skills/` (en separat Claude Code-mekanisme, der indlæses efter behov) eller i `docs/`. Brug en henvisning på én linje i CLAUDE.md: “Når du opretter en ny migrering, skal du åbne `docs/migrations.md`.” ### Fejl 4. Regler, der allerede kontrolleres af en automatisk kodeanalysator “Brug semikoloner”, “lad ikke ubrugte imports stå”, “brug ikke `var`”. ESLint, Prettier og Biome fanger alt dette - de er linters (automatiske kodekontrolværktøjer). En linter er deterministisk: Den kører, finder en fejl og retter den. En CLAUDE.md-regel er probabilistisk; agenten kan glemme den. Der er ingen grund til at gentage den - det er nemmere at konfigurere linteren. ### Fejl 5. Hemmeligheder i CLAUDE.md Jeg har set adgangskoder til testkonti, API-tokens til sandkasser og links til loginbeskyttede administrationspaneler. Alt sammen stod i en fil, der var checket ind i git og indlæst i Anthropics modelkontekst. Aldrig. Hemmeligheder hører hjemme i `.env`, som står i `.gitignore`. CLAUDE.md bør højst sige: “Læs ikke hele `.env`; brug `grep` til en bestemt variabel.” ### Fejl 6. En rodebunke på 500+ linjer, der ikke er ryddet op i seks måneder CLAUDE.md er vokset, indeholder halvdelen af `docs/` i kopi, modsiger sig selv flere steder, og ingen kan huske, hvad der står i den. Agenten begynder at ignorere det meste. Teamet klager over, at “Claude ikke følger instruktionerne”, og tilføjer flere regler, hvilket gør det værre. Tegn på en forsømt CLAUDE.md: over 300 linjer, gentagne regler i forskellige afsnit, forældede links til filer, der ikke længere findes, og “historiske” noter som “i 2024 besluttede vi at gøre det på denne måde, men skiftede senere mening”. Løsningen: Bed Claude gennemgå den hver anden uge med Anthropics test: “Hvis denne linje blev fjernet, ville agenten så begå en fejl?” Slet alt, hvor svaret er “nej”. ### Fejl 7. CLAUDE.md bliver oprettet og glemt Dette er det modsatte af den foregående fejl. Filen blev sat sammen én gang for to måneder siden og er ikke blevet rørt siden. I mellemtiden er værktøjerne ændret, nye mapper er blevet tilføjet, og nye agentfejl er dukket op. CLAUDE.md ved intet om dette, fordi ingen har opdateret den. Et tydeligt tegn: Du gentager den samme instruktion i hver session. “Gør ikke X”, “rør ikke Y”, “husk Z”. Hvis du har gentaget det mere end to gange, hører reglen hjemme i CLAUDE.md, ikke i dit hoved.
[Ailoot Guides](https://ailoot.ai/docs/)
## Hvordan gør du CLAUDE.md selvlærende med en regel om “opdatering ved slutningen af sessionen”?
Det vigtigste Den vigtigste teknik, der gjorde min CLAUDE.md til et levende værktøj i stedet for et dokument, var at tilføje én regel til filen: “I slutningen af hver session skal du kontrollere, om du har lært noget nyt om brugeren eller om, hvordan du skal arbejde sammen med vedkommende, som ikke står i CLAUDE.md, og tilføje en linje.” I løbet af to måneder begyndte filen at samle individuelle regler uden en separat proces.
Min CLAUDE.md har et kort afsnit: ```markdown ## Self-learning At the end of every session, check: - Have I learned anything new about the user or how to work with them? - Did I break any rule that should now be recorded? If so, create or update a file in `about-me/feedback/` in this format: Rule (one-line rule) → Why (why it was added) → How to apply (when it applies). I don’t write the rules by hand - I say, “not like that, because this is how,” and you put it into a file. ``` Efter at dette afsnit blev føjet til CLAUDE.md, begyndte Claude i slutningen af hver session at spørge: “Var der noget nyt, som er værd at skrive ned?” Hvis der var, foreslog den et udkast til en regel, jeg præciserede den, og der blev oprettet en fil. Efter to måneders arbejde på denne måde har jeg mere end to dusin filer i `about-me/feedback/` - regler, der er lært af konkrete fejl. Hver fil er én side i formatet Regel → Hvorfor → Hvordan. Mappen blev et “andet minde”, der registrerer mine personlige præferencer og tabuer. Hver fejl gentages ikke, fordi den bliver til en regel, og reglerne bygger oven på og styrker hinanden. Efter seks måneder kender Claude mit projekt bedre, end jeg selv husker det efter en måneds pause. ## Hvordan tilføjer du juridiske regler, markedsføring og drift til CLAUDE.md?
Det vigtigste Tekniske retningslinjer i CLAUDE.md er kun halvdelen af billedet. Den anden halvdel er forretningsregler: forbudte formuleringer af juridiske hensyn, formatering af ekstern tekst for brandet og driftsvaner for, hvordan teamet arbejder fra uge til uge. Når CLAUDE.md dækker begge sider, bliver Claude ikke kun programmør, men også redaktør og driftsassistent.
For de fleste teams er CLAUDE.md et rent teknisk dokument: værktøjer, build-kommandoer og kodekonventioner. Det er nyttigt, men udgør kun en tredjedel af værdien. Når en iværksætter vedligeholder CLAUDE.md, giver det mening at tilføje forretningsafsnit. Tre er vigtigst: ### Juridiske regler (for regulerede markeder) Hvis du publicerer tekst i en reguleret branche (finans, medicin, reklame for lægemidler, børneprodukter), har forbudte ord juridisk vægt og hører hjemme i CLAUDE.md som udtrykkelige regler. Ikke i nogens hoved, ikke på en redaktørs skærmbillede - i en fil, som agenten ser i hver session. Eksempel for et fintechprojekt uden banklicens: Redaktionel note: Følgende viser formatet på en intern regel for et bestemt projekt. Det er ikke en generel tilladelse til at bruge de nævnte termer: om et udsagn er acceptabelt, afhænger af gældende lovgivning og virksomhedens status. > 🚨 KRITISK - finansielle formuleringer er forbudt. Brug ikke “indskud”, “garanteret afkast” eller “investeringsprodukt” i materiale rettet mod kunder. Brug: “opsparingskonto”, “forventet afkast” og “produkt med variabel rente”. Årsagen er de juridiske krav, der gælder for markedsføring af finansielle tjenester i dette projekt. Denne blok i CLAUDE.md gør noget enkelt: Hver gang du beder Claude om at skrive kundevendt tekst, kontrollerer agenten den op mod forbuddene. Uden reglen dukker forbudte ord op i hver tredje kampagne. Med den glemmer du, at de findes. Den samme tilgang virker for: - Medicinske projekter (ingen påstande om, at noget “behandler” eller “helbreder”). - Reklame for lægemidler (ingen påstande om “mest effektiv”; påkrævede advarsler). - Enhver reguleret branche med sine egne reklameregler. ### Markedsføringsstil og tekstformat Hvis du publicerer tekst regelmæssigt (sociale medier, nyhedsbreve, websites), er det værd at dokumentere formatet i ét afsnit i CLAUDE.md. Her er et eksempel på, hvad en influencer eller et bureau, der driver en beskedkanal, kunne skrive: > Når du skriver opslag til kanalen, skal du læse `style/posts.md`. Brug kanalens tilladte formateringsmarkører, og undgå “farlige” specialtegn. Afslut med en CTA med et UTM-tag efter denne konvention: `utm_source=&utm_medium=&utm_campaign=`. Claude plejede at skrive opslag i “den generelle stil fra en marketingwebsite”. Nu følger den dit format, bruger dine UTM'er og afslører ikke, at teksten er skrevet af AI. ### Driftsvaner Udløsertabeller. Når du siger en bestemt formulering, ved agenten, hvilke filer den skal åbne, og hvilke handlinger den skal udføre. Her er et eksempel for et team, der planlægger uge for uge: > “Planlæg ugen” → åbn `ops/monthly.md`, opret `YYYY-WNN.md` i samme mappe, og flyt opgaverne fra `ops/backlog.md` til de relevante dage. “Hvad står på efterslæbslisten?” → læs `ops/backlog.md`, og vis den som en liste. “Afslut ugen” → udfyld afsnittet “Ugeopsummering” i den aktuelle uges fil. Med sådanne tabeller går Claude fra at være en “hjælper, der skriver kode” til en “operatør”, der kender virksomhedens rutiner. Hver mandag siger jeg “lad os planlægge ugen”, og Claude åbner de rigtige filer, læser månedens mål og foreslår, hvordan opgaverne kan opdeles.
Bemærk Forretningsspecifik vejledning i CLAUDE.md giver mening, når du allerede har en `business/`-mappe med reel kontekst om din målgruppe, dine produkter og dine mål. Hvis du ikke har en, skal du først oprette `business/` og derefter tilføje henvisninger til den i CLAUDE.md. Ellers vil du have instruktioner, der peger på ingenting.
## Hvordan kontrollerer du din CLAUDE.md mod en tjekliste med 12 punkter på 5 minutter?
Det vigtigste Gennemgå din nuværende CLAUDE.md med denne tjekliste. Hvert punkt tager 30 sekunder. Hvis du har fem eller flere svar med “nej”, trænger filen til en oprydning.
1. **Størrelse.** Er filen kortfattet, med cirka 200 linjer som mål for gennemgang frem for et bestået/ikke-bestået-loft? 2. **Navn.** Hedder den præcis `CLAUDE.md` med store bogstaver, ikke `claude.md`? 3. **Placering.** Ligger den i projektroden eller i `./.claude/CLAUDE.md`? 4. **Projektbeskrivelse.** Gør de første 5 linjer det klart, hvad projektet er, og hvem det er til? 5. **Værktøjer.** Er teknologierne angivet eksplicit og uden fyld? 6. **Struktur.** Er der et repository-diagram med forklaringer? 7. **Henvisninger.** Er der en tabel med “spørgsmål → fil”, der viser, hvor man finder svar? 8. **Principper.** Er der et afsnit med regler, der begynder med “aldrig” og “altid”? 9. **Specificitet.** Kan hver regel verificeres? (“Brug 2 mellemrum”, ikke “skriv smukt”.) 10. **Selvopdatering.** Er der en regel om at “kontrollere, hvad der skal tilføjes ved slutningen af sessionen”? 11. **Refleksion.** Er der en regel om at “notere sessionsopsummeringen i `retrospectives/`”? 12. **Sikkerhed.** Er kritiske forbud (`.env`, `rm -rf`) også med i `.claude/settings.json`? Hvis du har mere end fem svar med “nej”, skal du åbne Claude og give den denne prompt:
Prompt: Gennemgå CLAUDE.md ud fra tjeklisten ``` Læs min CLAUDE.md, og sammenlign den med tjeklisten nedenfor. For hvert punkt skal du sige: ja / nej / delvist, og hvad der konkret skal rettes. Tjekliste: Kompakt nok til opgaven; gennemgå omkring 200 linjer uden at behandle det som et hårdt loft Projektbeskrivelse i de første 5 linjer Værktøjer angivet eksplicit Diagram over repository-strukturen inkluderet Tabel med “spørgsmål → fil” inkluderet Afsnit med principper og regler inkluderet Alle regler er konkrete og kan verificeres Reglen “Opdatér ved slutningen af sessionen” er inkluderet Reglen “Reflektér ved slutningen af sessionen” er inkluderet Kritiske forbud er inkluderet i .claude/settings.json Ingen dubletter af samme regel i forskellige afsnit Ingen døde links til filer, der ikke længere findes Efter gennemgangen skal du give mig en liste over konkrete ændringer, der gør filen levende. ```
## Hvad skal du bruge efter CLAUDE.md: Plan Mode, Skills eller sub-agenter?
Det vigtigste CLAUDE.md er fundamentet. Når den fungerer, er næste niveauer tilgængelige: Plan Mode (få Claude til at planlægge først og handle bagefter), Skills (flyt sjældent brugt viden ud af CLAUDE.md til separate filer) og sub-agenter (isolerede opgaver i deres egne kontekster).
CLAUDE.md er fundamentet. Når den fungerer, kan du tilføje tre Claude Code-mekanismer, der understøtter hinanden. **Plan Mode.** En tilstand, hvor Claude først udarbejder en plan for ændringer, venter på din godkendelse og først derefter begynder at arbejde. Aktivér den med Shift+Tab eller kommandoen `/plan`. Den håndterer den største irritation ved vibe coding: “Jeg bad Claude rette én ting, og den skrev halvdelen af projektet om.” Det sker ikke i Plan Mode - du ser planen, før agenten rører nogen filer. **Skills.** Separate `.md`-filer i mappen `.claude/skills/` med viden om en bestemt type opgave. For eksempel indeholder en skill om “hvordan man skriver en databasemigrering” en specifik procedure, en skabelon og eksempler. Denne viden står ikke i CLAUDE.md, fordi den er for omfattende. Men når Claude får en opgave som “skriv en migrering”, indlæser den den relevante skill og følger den. **Sub-agenter.** Når en opgave kræver meget kontekst (for eksempel gennemgang af en stor funktion), kan Claude starte en separat sub-agent i sin egen, rene kontekst. Sub-agenten udfører arbejdet og returnerer resultatet uden at fylde hovedchattens kontekst. Alle tre mekanismer bruger CLAUDE.md som indgangspunkt: De læser den i begyndelsen af arbejdet for at forstå projektets kontekst. Derfor fungerer disse funktioner også dårligt uden en levende CLAUDE.md. Først fundamentet, derefter lagene ovenpå. **Næste skridt.** Opret en `CLAUDE.md` i projektroden, kopiér skabelonen fra begyndelsen af artiklen, og udfyld felterne i kantede parenteser ved hjælp af hjælpeprompten. Brug derefter filen i hverdagen: Gør hver agentfejl til en ny linje. Efter to eller tre uger holder CLAUDE.md op med at være “et dokument, vi skrev og glemte”, og bliver noget, Claude faktisk bruger i hver session. Hvis du vil bygge et komplet rammeværk omkring `CLAUDE.md` - en `business/`-mappe til en Second Brain, en `about-me/`-mappe til en digital afspejling af dig, grundlæggende skills og en konfigureret Plan Mode - så brug trinnene og eksemplerne i denne artikel. [Ailoot Guides](https://ailoot.ai/docs/).
### Kilder - [Anthropic - Claude Code Memory](https://code.claude.com/docs/en/memory) - officiel dokumentation om CLAUDE.md, MEMORY.md og indlæsningshierarkiet - [Anthropic - Best Practices](https://code.claude.com/docs/en/best-practices) - regler for at skrive en effektiv CLAUDE.md og testen “ville Claude begå fejl, hvis dette blev fjernet?” - [Anthropic Support - Give Claude Context](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts) - supportvejledning til arbejde med kontekst - [Ailoot Guides](https://ailoot.ai/docs/) - dokumentation.
[Fortsæt med Ailoot](https://ailoot.ai/).
[Fortsæt med Ailoot](https://ailoot.ai/)
[Fortsæt med Ailoot](https://ailoot.ai/)
## Spørgsmål og svar ### Bliver en CLAUDE.md-fil ugyldig efter 200 linjer? Nej. Anbefalingen er et mål for kompakthed, ikke et parserloft eller et garanteret fejlpunkt. Gennemgå dubletter, modstridende regler og indlæst kontekst, og test derefter de vigtige regler på repræsentative opgaver. Artikeltallet på 280 linjer skal vurderes på samme måde. ### Hvad skal flyttes ud af en voksende CLAUDE.md? Flyt detaljerede procedurer, langt referencemateriale og beslutningshistorik til relevante dokumenter eller skills. Behold korte projektfakta, væsentlige begrænsninger og tydelige links i indgangsfilen. Gentag reelle opgaver efter redigering for at kontrollere, at henvisninger og kritiske regler stadig virker. ## Ailoot · Virksomheden og dens projektportefølje Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI. Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder. Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.