
CLAUDE.md-best practices: 9 regler, der forhindrer Claude i at ignorere dig (2026)
De fleste indlæg om CLAUDE.md-best practices giver dig en skabelon og kalder det klaret, men den fil, du skrev i sidste uge, bliver sandsynligvis allerede ignoreret, og du ved ikke hvorfor. Løsningen er sjældent "tilføj flere regler." Det er som regel det modsatte. Vi har implementeret Claude Code på alle vores seneste kundeprojekter, og disse 9 regler er det, der faktisk rykker noget: et hierarki, der matcher den måde, Claude indlæser filer på, et instruktionsbudget, du ikke kan overskride, beslutningen om AGENTS.md og de seks grunde til, Claude stille og roligt dropper din fil midt i en session.
Nøglepointer
- CLAUDE.md er projektets hukommelse, som indlæses i Claude Codes kontekst – hold den under 200 linjer, ellers begynder regler at blive droppet.
- Filer indlæses oppefra og ned: global, projektrod, undermappe (dovent) og CLAUDE.local.md (personlig, gitignored).
- Brug AGENTS.md, hvis du også kører Cursor eller Copilot; symlink CLAUDE.md til AGENTS.md for at ramme begge.
- Hvis Claude ignorerer din fil, skyldes det i 90 % af tilfældene længde, vaghed eller en manglende "hvorfor".
Hvad CLAUDE.md faktisk gør (og hvorfor det betyder noget)
Kort sagt: CLAUDE.md er en markdown-fil, som Claude Code læser som projekt hukommelse ved starten af hver session. Det er ikke en systemprompt, en hook eller en skill – det er vejledende kontekst, der skubber Claude i retning af jeres teams konventioner. Tænk på den mindre som dokumentation og mere som en konfigurationsfil, som jeres AI-parprogrammør rent faktisk læser.
Mange teams skriver CLAUDE.md som en README. Det er den første fejl. En README forklarer projektet til mennesker, der kan skimme og springe over. CLAUDE.md indtages i sin helhed af Claude Code ved sessionsstart, hvor hver linje koster tokens og overholdelse. Den minder langt mere om en konfigurationsfil eller et sæt testfixtures end om dokumentation.
Det er heller ikke den eneste måde at styre Claude på. Hooks udfører deterministiske handlinger (formatering, blokering af commits). Skills samler genanvendelige workflows. CLAUDE.md ligger derimellem som vejledende kontekst – Claude evaluerer den, tilsidesætter den nogle gange og glemmer helt sikkert dele af den, hvis I skriver for meget. Den skelnen er grundlaget for alt det følgende, og det er grunden til, at CLAUDE.md er ét værktøj i den bredere praksis med kontekstengineering, ikke en universalløsning.
Regel #1: Behandl den som kode, ikke dokumentation. Versionér den. Review den i PR'er. Trim den, som I ville refaktorere et oppustet modul. Ifølge Anthropics CLAUDE.md-guide indlæses filen med samme prioritet som enhver systeminstruktion, hvilket betyder, at en forældet regel fra for seks måneder siden stadig aktivt former hvert eneste svar i dag.
Hvordan CLAUDE.md indlæses: 4-trins-hierarkiet
Kort sagt: Claude Code indlæser CLAUDE.md fra fire trin: globalt (
~/.claude/CLAUDE.md), projektroden,CLAUDE.local.mdtil personlige tilsidesættelser og undermappefiler, der lazy-loader, kun når Claude læser filer i den pågældende mappe. Søskende-undermapper ser aldrig hinandens CLAUDE.md, hvilket holder Claude Code-hukommelsen stramt afgrænset.

Hierarkiet er den suverænt mest misforståede del af CLAUDE.md, og det er her, 0 af de øverste 5 SERP-resultater går i dybden. Her er, hvad der faktisk foregår under kølerhjelmen:
| Trin | Placering | Indlæses når | Omfang | Git |
|---|---|---|---|---|
| Global | ~/.claude/CLAUDE.md | Sessionsstart | Alle projekter på din maskine | Personlig |
| Projektrod | ./CLAUDE.md | Sessionsstart | Hele repoet | Committet |
| Lokal | ./CLAUDE.local.md | Sessionsstart | Dette checkout, din maskine | Gitignored manuelt |
| Undermappe | ./frontend/CLAUDE.md osv. | Dovent, når Claude læser filer i den mappe | Det pågældende deltræ | Committet |
To begreber, der er værd at få på plads: lazy loading og sibling isolation.
Lazy loading betyder, at en undermappe-CLAUDE.md ikke kommer ind i Claudes kontekst, før Claude faktisk åbner en fil i den mappe. Hvis du beder om "fix login-buggen", og Claude kun rører backend/, bliver din frontend/CLAUDE.md aldrig indlæst. Det er godt, det holder kontekstvinduet rent, men det bider teams, der lægger kritiske regler i undermapper i forventning om, at de altid gælder.
Sibling isolation er følgeslutningen: frontend/CLAUDE.md og backend/CLAUDE.md indlæser aldrig hinanden. De deler kun det, der ligger i projektroden. Så hvis dine frontend-regler modsiger dine backend-regler, er det fint. Hvis de har brug for at dele en konvention, så skub den op i rodfilen.
CLAUDE.local.md er nødudgangen. Den indlæses, men committes ikke — perfekt til "jeg foretrækker pnpm, men teamet har standardiseret på npm"-agtige tilsidesættelser. Hagen: den gitignores ikke automatisk. Du skal selv tilføje den. Glemmer du det, committer du dine personlige regler ind i teamets repo.
Regel #4: Placér instrukser, hvor Claude faktisk læser dem. Stilregler for React-komponenter hører til i frontend/CLAUDE.md, ikke i roden. Regler for databasemigrering hører til i backend/. Anthropics Memory-dokumentation (opdateret november 2025) bekræfter dette — lazy-load-adfærden er tilsigtet og bærende.
Hvad du skal putte i CLAUDE.md (og hvad du skal lade være med)
Kort sagt: I CLAUDE.md hører alt det, som Claude ikke selv kan udlede af din kode: build-kommandoer, navngivningskonventioner, anti-mønstre dit team har brændt sig på, og hvorfor bag hver regel. Ude bliver alt, hvad der står i README'en, alt i
package.jsonog enhver regel, der ændrer sig ugentligt. claude code-instruktioner bør være testbare og specifikke.
Her er en minimal CLAUDE.md, der faktisk gør nytte:
# Projekt: techsy-app
## Kommandoer
- Build: `pnpm build` (Turbopack — Webpack-flag gælder ikke)
- Test: `pnpm test --run` (vi bruger Vitest, ikke Jest)
- Lint: `pnpm lint` (fejler CI ved advarsler, ikke kun fejl)
## Konventioner
- Serverkomponenter som standard. Tilføj kun `'use client'`, når det virkelig er nødvendigt.
Hvorfor: Vi oplevede 8 sekunders LCP i sidste kvartal på grund af for mange klientkomponenter.
- Databaseadgang kun via `lib/db/`-hjælpefunktioner — aldrig rå SQL i ruter.
Hvorfor: Politikker for rækkeniveausikkerhed ligger i disse hjælpefunktioner.
- Tests placeres som `*.test.ts` ved siden af den fil, der testes.
## Undgå
- Tilføj ikke en ny dependency uden først at åbne en PR-kommentar.
- Brug ikke `any` — brug `unknown` og indsnævr typen.
## Hvor du skal kigge
- Skema: `db/schema.ts`
- Godkendelsesflow: `lib/auth/README.md`Now compare that to the anti-pattern version most teams ship:
# Projektregler
- Skriv ren, vedligeholdelsesvenlig kode.
- Følg bedste praksis.
- Brug TypeScript korrekt.
- Sørg for, at testene består.
- Vær konsistent med eksisterende mønstre.
- Dokumentér kompleks logik.Den anden fil er ikke forkert. Den er bare ubrugelig. Claude vil allerede gerne skrive ren kode. "Vær konsistent" fortæller ikke Claude, hvilket mønster det skal være konsistent med. De offentlige eksempler fra Anthropic-ingeniøren Boris Cherny hælder stærkt mod den første stil: konkrete kommandoer, navngivne værktøjer og hvorfor'et bag beslutninger, der ikke er indlysende ud fra kodebasen alene.
Regel nr. 2: Vær specifik, ikke aspirerende. "Skriv ren kode" er aspirerende. "Serverkomponenter som standard; tilføj kun 'use client', når det virkelig er nødvendigt" er testbart. Den samme disciplin ligger til grund for god prompt engineering: specifikke, testbare instruktioner slår vage ambitioner, uanset om de findes i en prompt eller en CLAUDE.md.
Regel nr. 3: Forklar hvorfor hver regel er vigtig. "Hvorfor'et" er ikke fyld, det er sådan, Claude træffer beslutninger i grænsetilfælde. En regel med en begrundelse ("vi ramte 8s LCP på grund af for meget client-side kode") kan generaliseres til lignende situationer. En regel uden en begrundelse bliver ignoreret, i det øjeblik konteksten ændrer sig. Mønstret er også dokumenteret i Builder.ios CLAUDE.md-guide.
Hvorfor ignorerer Claude din CLAUDE.md? Instruktionsbudgettet
Kort sagt: Claude er ikke ondskabsfuld – den løber tør for opmærksomhed. Efter cirka 80 linjer vil du bemærke, at regler begynder at blive droppet; efter 200 linjer ignoreres store blokke helt; efter 500 ord med tætte regler bryder overholdelsen sammen. Løsningen er et instruktionsbudget. Behandel hver linje som en omkostning på claude code memory og overholdelse per regel.
Nyere forskning bekræfter det, produktionsbrugere bliver ved med at opdage: instruktionsoverholdelse forringes ikke-lineært med antallet af regler. arxiv-artiklen 2507.11538 om instruktionsoverholdelseskapacitet viser, at overholdelsen per regel falder, efterhånden som du stabler flere, og HumanLayers analyse af CLAUDE.md i produktion gentager det samme resultat.
Oversat: hver regel du tilføjer gør alle andre regler en smule mindre sandsynlige at blive fulgt. Så en CLAUDE.md på 400 linjer er ikke 4x så effektiv som en på 100 linjer. Den er ofte mindre effektiv, fordi de regler, du faktisk går op i, bliver udvandet af dem, du skrev en fredag for tre måneder siden og aldrig slettede.
I vores CLAUDE.md-filer begynder alt efter linje 150 at miste overholdelse på synlig vis. Ved linje 250 har vi set Claude springe hele sektioner over. Så vi sætter et loft.
wc -l CLAUDE.mdDet er hele værktøjet. Kør det. Hvis du er over 200, er du over budget. Den hårde regel, vi leverer til kunder:
Behandl CLAUDE.md som et 200-linjers budget. Hver linje koster overholdelse. Brug den, hvor det betyder noget.
Regel #1 forstærket: Hold det kort. Under 200 linjer. Under 500 ord med tætte regler. Hvis du mærker trangen til at tilføje automatiseringsregler ("kør altid prettier efter redigeringer"), hører de sandsynligvis til i Claude Code hooks i stedet – hooks er deterministiske og koster ikke instruktionsbudget-tokens.
Bør du bruge CLAUDE.md, AGENTS.md, .cursorrules eller copilot-instructions?
Kort sagt: Hvis du kun bruger Claude Code, er CLAUDE.md fint. Hvis du bruger to eller flere agent-CLI'er (Codex, Cursor, Copilot, Sourcegraph), så skift til AGENTS.md og symlink CLAUDE.md til AGENTS.md. AGENTS.md opstod i slutningen af 2025 som en standard på tværs af værktøjer, og de fleste moderne agenter falder tilbage på den, så en enkelt fil kan forsyne alle økosystemer.
Dette er spørgsmål 0, som de 5 bedste søgeresultater faktisk besvarer. Her er matricen:
| Fil | Værktøj | Omfang | Hvornår den bruges | Fallback |
|---|---|---|---|---|
CLAUDE.md | Claude Code | Pr. projekt + global | Teams der kun bruger Claude Code | Claude læser kun denne |
AGENTS.md | OpenAI Codex, Cursor, Sourcegraph, Factory, Google | Pr. projekt | Du bruger 2+ agent-CLI'er | De fleste agenter falder tilbage på den |
.cursorrules | Cursor | Pr. projekt | Kun Cursor eller som Cursor-specifikt supplement | Kun Cursor |
.github/copilot-instructions.md | GitHub Copilot | Pr. projekt | Kun Copilot | Kun Copilot |
Tricket med dobbelt mål er én linje:
ln -s AGENTS.md CLAUDE.mdDet var det. Nu læser Claude Code, Codex og alle værktøjer, der understøtter AGENTS.md, den samme fil. Opdatér én gang, så læser alle agenter den. AGENTS.md-specifikationen er åben og bevidst minimal — det er bare markdown med konventionelle sektioner.
To udfordringer fra den virkelige verden. For det første: Hvis dit team har en Cursor-superbruger, tager Cursors .cursorrules en anden tilgang: enkelt fil, intet hierarki, mere stift format. Nogle teams beholder begge: AGENTS.md til de delte regler, .cursorrules til Cursor-specifikke særheder. For det andet: Copilots .github/copilot-instructions.md falder ikke tilbage på AGENTS.md, så teams, der bruger meget Copilot, har brug for en separat fil.
Hvis du vælger en agent-stak fra bunden, dækker vores gennemgang af Claude Code vs. Cursor vs. Copilot afvejningerne på brugsniveau. Den korte version: Claude Codes hierarki er det mest kraftfulde til monorepos, Cursors UX vinder til soloarbejde, og Copilots IDE-integration er stadig den mest problemfri til trinvis adoption.
Regel #9: Brug AGENTS.md, hvis du kører mere end én agent-CLI. Vedligehold ikke to filer, der siger det samme. Vælg den fil, som det meste af din stak læser, og symlinke resten.
CLAUDE.md vs. Hooks vs. Skills: Beslutningstrekanten
Kort sagt: CLAUDE.md = rådgivende kontekst. Hooks = deterministiske handlinger. Skills = bundtede funktioner. Vælg den forkerte, og du brænder instruktionsbudget af på noget, en hook burde håndtere, eller skriver en CLAUDE.md-regel for noget, kun en skill kan levere. Trekanten er den billigste måde at holde CLAUDE.md slank på.

Tre værktøjer, tre opgaver. Den fejl, vi ser oftest: at lægge "kør altid prettier efter redigering" i CLAUDE.md. Claude læser den. Claude kører nogle gange prettier. Du bliver frustreret. Løsningen er at flytte den linje ud af CLAUDE.md og ind i en hook, fordi hooks affæres deterministisk hver gang uden rådgivende spillerum.
| Brugsscenarie | Værktøj | Hvorfor |
|---|---|---|
| Kør prettier ved gemning | Hook | Deterministisk, skal altid ske |
| Brug indrykning med 2 mellemrum | CLAUDE.md | Rådgivende stilpræference |
| Kør vores testpipeline med vores konfiguration | Skill | Genanvendeligt, bundtet workflow |
| Bloker commits til main | Hook | Hård regel, ingen forhandling |
| Foretræk funktionelle komponenter frem for klasser | CLAUDE.md | Stilvejledning, som Claude evaluerer |
| Generer et Sanity-skema | Skill | Flertrinsfunktion med aktiver |
Hvis en regel altid skal affæres, hører den hjemme i en hook. Hvis det er en stilpræference, Claude kan vurdere i forhold til konteksten, hører den hjemme i CLAUDE.md. Hvis det er et workflow med flere trin og bundtede aktiver (skabeloner, scripts, prompts), hører det hjemme i en skill.
Regel #8: Vælg korrekt mellem CLAUDE.md, hooks og skills — at lægge en hook i CLAUDE.md er det mest almindelige spild af instruktionsbudget. Konfigurer deterministiske handlinger med Claude Code hooks, og pak genanvendelige workflows som Claude skills. Din CLAUDE.md bliver kortere, dine værn bliver mere solide, og Claude holder op med at "glemme" de regler, der betyder noget.
Monorepo-mønstre: Indlejret CLAUDE.md, @imports og .claude/rules/
Kort sagt: I et monorepo skal root-CLAUDE.md være minimal — kun pointere og delte konventioner. Skub detaljerne ud i
apps/*/CLAUDE.md, så hvert undertre har afgrænsede regler. Brug @imports til at dele modulære regelfiler via.claude/rules/. Det er progressiv videregivelse — Claude henter kun hver del, når den er relevant.
Et typisk monorepo-CLAUDE.md-træ:
.
├── CLAUDE.md # 30 lines — points to subdirs and shared rules
├── .claude/
│ └── rules/
│ ├── style.md
│ ├── testing.md
│ └── security.md
├── apps/
│ ├── web/
│ │ └── CLAUDE.md # Next.js-specific rules
│ └── api/
│ └── CLAUDE.md # Fastify-specific rules
└── packages/
└── shared/
└── CLAUDE.md # Library author rules@import-syntaksen lader root-filen hente delte regelbidder uden at gentage dem:
# Root CLAUDE.md
Dette er et Turborepo. Se CLAUDE.md i undermapper for appspecifikke regler.
@import .claude/rules/style.md
@import .claude/rules/testing.md
@import .claude/rules/security.md
## Kommandoer på øverste niveau
- `pnpm dev` kører alle apps parallelt
- `pnpm test` kører alle workspaces testscriptDet er progressiv afsløring i praksis. Rodfilen er en 30-linjers henvisning. Hver undermappe-CLAUDE.md tilføjer 50–80 linjer med fokuserede regler. Filerne i .claude/rules/ indeholder konventionsblokke, som flere undermapper kan trække ind. Intet er duplikeret, intet bliver overset, og ingen enkelt fil overskrider instruktionsbudgettet.
Lazy-loading-reglen fra tidligere er endnu vigtigere her: Når Claude arbejder på apps/web/Button.tsx, ser den rodfilen plus apps/web/CLAUDE.md plus de @import-erede regelfiler. Den ser ikke apps/api/CLAUDE.md. Det er hele pointen — backend-konventioner forurener ikke frontend-konteksten, og dit kontekstvindue forbliver brugbart.
Regel #6: Brug @imports til at holde rodfilen under 200 linjer. Guiden Anthropic Best Practices for Claude Code behandler dette som standardmønsteret for monorepos. Underagenter arver også forælderens CLAUDE.md-kontekst, hvilket er værd at vide, hvis du indlejrer workflows — se kontekst-engineering for hvordan det spiller sammen med underagentdesign.
6 grunde til, at Claude ignorerer din fil (og løsningen på hver)
Kort sagt: Når Claude ignorerer CLAUDE.md, skyldes det næsten altid én af seks årsager: filen er for lang, vag formulering, manglende "hvorfor", kontekstkomprimering, en modstridende overordnet fil eller et forkert filnavn. Hver af dem har en 60-sekunders løsning. Test i en ny session efter hver ændring – det er regel nr. 7.
1. Filen er for lang (>200 linjer / >500 ord)
Kør wc -l CLAUDE.md. Hvis den er over 200, så beskær den aggressivt. Flyt automatiseringsregler til hooks. Flyt workflows til skills. Opdel fælles kodestumper i .claude/rules/ og hent dem ind med @import. Den hyppigste årsag til, at Claude "holdt op med at følge" dine regler, er, at filen med tiden blev for lang, og overholdelsen stille og roligt smuldrede.
2. Vag formulering ("skriv ren kode")
Erstat enhver ambitiøs regel med en specifik, testbar én. "Vær konsistent" er usynligt for Claude. "Brug serverkomponenter som standard; tilføj kun 'use client' til formularer eller interaktiv UI" er noget, Claude faktisk kan anvende.
3. Manglende "hvorfor"
Regler uden begrundelser generaliserer ikke. Claude kan ikke udlede, hvornår reglen bør bøjes, fordi den ikke ved, hvad reglen beskytter imod. Hver ikke-indlysende regel får en kort forklaring: "Vi bruger unknown og ikke any, fordi vi havde tre runtime-nedbrud i sidste kvartal som følge af API-svar, der var typet som any."
4. Kontekstkomprimering kasserede den
Lange sessioner udløser komprimering, Claude opsummerer tidligere kontekst for at få plads i vinduet, og indholdet i CLAUDE.md bliver nogle gange opsummeret til intethed. Løsningen: /clear efter større kontekstforbrug, eller genstart sessionen helt. Det er præcis det, GitHub Issue #17530 gang på gang påpeger.
5. Modstridende overordnede CLAUDE.md
Den globale siger "brug 4 mellemrum." Projektroden siger "brug 2 mellemrum." Underkataloget siger ingenting. Claude vælger én, nogle gange den forkerte. Gennemgå ~/.claude/CLAUDE.md og projektroden for modsigelser. Den, der er mest specifik, bør vinde, men kun hvis du gør det eksplicit.
6. Forkert filplacering eller forskel på store og små bogstaver i filnavnet
Claude.md og CLAUDE.md er forskellige filer på Linux og macOS. Det samme gælder claude.md og CLAUDE.md. Bekræft, at stien er præcis ./CLAUDE.md (med store bogstaver), og bekræft, at Claude Code startes fra den mappe, der indeholder den. GitHub Issue #668 er fuld af tilfælde, hvor filen fandtes, men Claude ikke kunne se den på grund af stiplaceringen.
Regel #7: Test i en ny session. Åbn en ny session efter enhver ændring i CLAUDE.md, og bed Claude om at "opsummere reglerne i CLAUDE.md." Hvis opsummeringen mangler noget, gør filen ikke sit arbejde.
Din første CLAUDE.md på 10 minutter: En 5-trins begynderguide
Kort sagt: Kør
/initfor at lave et udkast, trim det til 6–10 reelle regler med begrundelser, tilføj 3 kommandoer, Claude bør kende, tilføj 2 anti-mønstre, dit team er stødt på, og test derefter i en ny session ved at bede Claude om at opsummere filen. Samlet tid: cirka 10 minutter. 5-trinsopskriften er præcis det, vi bruger på dag 1 i hvert nyt repo.
-
Kør
/initfor at lave et udkast. Claude Codes/init-kommando scanner dit repo og skriver en begynder-CLAUDE.md. Send ikke det, den skriver, i produktion./init-output er et udgangspunkt, ikke en færdig fil, og ærlig talt kan det meste af det, den genererer, godt undværes. -
Trim den til 6–10 linjer med reelle regler og begrundelser. Slet alt, der er generisk. Slet alt, der står i README'en. Behold kun regler, som Claude ikke selv kan udlede af koden.
-
Tilføj 3 kommandoer, Claude bør kende. Build, test, lint. Angiv den præcise kommando og alle ikke-åbenlyse flag. Hvis I bruger Vitest og ikke Jest, så sig det.
-
Tilføj 2 anti-mønstre, dette team er stødt på. Ægte nogle. "Brug ikke
any, for vi havde tre runtime-nedbrud" slår "brug TypeScript korrekt" hver gang. -
Åbn en ny session, og verificér. Bed Claude om at "opsummere reglerne i CLAUDE.md." Hvis den overser noget, er filen for lang, for vag eller mangler et "hvorfor." Ret det, og gentag.
Regel #5: Autogenerér ikke kun fra /init. /init er et udgangspunkt, ikke en færdig fil. De 8 minutter, du bruger på at trimme den, er der, hvor værdien ligger.
Ofte stillede spørgsmål
Hvad er en CLAUDE.md-fil?
En CLAUDE.md-fil er en markdown-fil, som Claude Code læser som projekthukommelse i starten af hver session. Den fortæller Claude om dine konventioner, kommandoer og anti-mønstre, så den ikke behøver at gætte. Den fungerer på fire niveauer: globalt, projektrod, undermappe (lazy-loaded) og en personlig CLAUDE.local.md, som du holder gitignored.
Hvor lang bør en CLAUDE.md-fil være?
Under 200 linjer og under 500 ord med tætte regler. Ud over disse grænser forringes Claudes evne til at følge instruktioner – hver regel, du tilføjer, gør det lidt mindre sandsynligt, at alle andre regler følges. Betragt det som et fast budget. Hvis du har brug for mere, så opdel i CLAUDE.md-filer i undermapper og brug @import til delte bidder.
Hvor skal jeg placere CLAUDE.md?
Den primære fil placeres i dit projektrod (./CLAUDE.md) og committes. Tilføj CLAUDE.md-filer i undermapper til app-specifikke regler i monorepos. Placer projektoverskridende præferencer i ~/.claude/CLAUDE.md. Brug CLAUDE.local.md til personlige tilsidesættelser, du ikke vil have committet, men husk at gitignore den manuelt.
Hvorfor ignorerer Claude min CLAUDE.md?
90 % af tilfældene skyldes én af tre ting: filen er for lang (over 200 linjer), reglerne er vage ("skriv ren kode"), eller også mangler reglerne en "hvorfor", som Claude kan bruge til at anvende dem. Kør wc -l CLAUDE.md, og gennemgå derefter filen for præcision. Test ændringerne i en ny session ved at bede Claude om at opsummere filen.
Skal jeg bruge CLAUDE.md eller AGENTS.md?
Hvis dit team kun bruger Claude Code, så hold dig til CLAUDE.md. Hvis du bruger to eller flere agent-CLI'er (Codex, Cursor, Sourcegraph), så skift til AGENTS.md og symlink CLAUDE.md til den: ln -s AGENTS.md CLAUDE.md. De fleste moderne agent-CLI'er falder tilbage på AGENTS.md, så én fil kan betjene alle værktøjer.
Skal jeg køre /init for at generere CLAUDE.md?
Ja, som et udkast. Nej, som en færdig fil. /init scanner dit repo og genererer en startversion, men den er omstændelig og generisk. Både Anthropic og HumanLayer anbefaler at beskære aggressivt efter at have kørt /init. Det er de 8 minutter, du bruger på at skære ned og tilføje "hvorfor"-linjer, der gør, at filen faktisk bliver nyttig.
Hvordan fungerer CLAUDE.md-filer i et monorepo?
Rod-CLAUDE.md forbliver minimal — kun pointere og delte regler. Hver app får sin egen apps/*/CLAUDE.md med afgrænsede konventioner. Filer i undermapper indlæses først, når Claude læser filer i det pågældende undertræ, så søskende forbliver isolerede. Brug @import .claude/rules/style.md til at dele modulære regelblokke uden at duplikere dem på tværs af apps.
Hvad er forskellen mellem CLAUDE.md, hooks og skills?
CLAUDE.md er vejledende kontekst, Claude læser den og følger den som regel. Hooks er deterministiske handlinger, der altid udløses (formatering, blokering af commits). Skills er samlede funktioner til genanvendelige workflows med aktiver. Brug CLAUDE.md til stilvejledning, hooks til hårde regler og skills til flertrinsopgaver, du vil gentage på tværs af projekter.
Sådan griber Techsy det an
Hos Techsy har alle de Claude Code-projekter, vi leverer, en CLAUDE.md på under 150 linjer og et AGENTS.md-symlink. Vi behandler filen som kode, versionerer den, gennemgår ændringer i PR'er og gentester i nye sessioner inden merge. Har du brug for hjælp til at integrere AI-agenter i din udviklingsworkflow? Få en gratis konsultation.