CLAUDE.md beste praksiser: 9 regler som får Claude til å faktisk følge instruksjonene dine (2026)

CLAUDE.md beste praksiser: 9 regler som får Claude til å faktisk følge instruksjonene dine (2026)

De fleste innlegg om CLAUDE.md beste praksiser gir deg en mal og kaller det ferdig — men filen du skrev forrige uke blir sannsynligvis allerede ignorert, og du vet ikke hvorfor. Løsningen er sjelden «legg til flere regler.» Det er som regel det motsatte. Vi har levert Claude Code på alle nyere klientprosjekter, og disse 9 reglene er det som faktisk gjør en forskjell: hierarki som matcher hvordan Claude laster filer, et instruksjonsbudsjett du ikke kan bryte, AGENTS.md-valget, og de seks grunnene til at Claude stille dropper filen din midt i en økt.

Viktige poenger

• CLAUDE.md er prosjektminne som lastes inn i Claude Codes kontekst — hold den under 200 linjer, ellers begynner regler å falle ut.
• Filer lastes ovenfra og ned: global, prosjektrot, undermappe (lat lasting) og CLAUDE.local.md (personlig, gitignorert).
• Bruk AGENTS.md hvis du også kjører Cursor eller Copilot; symlink CLAUDE.md til AGENTS.md for å nå begge.
• Hvis Claude ignorerer filen din, er det 90 % av gangene på grunn av lengde, vage regler eller manglende «hvorfor».

Hva CLAUDE.md faktisk gjør (og hvorfor det betyr noe)

Kort sagt: CLAUDE.md er en markdown-fil Claude Code leser som prosjektminne ved starten av hver økt. Det er ikke en systemprompt, en hook eller en skill — det er rådgivende kontekst som dypper Claude i retning av teamets konvensjoner. Tenk på det mindre som dokumentasjon og mer som en konfigurasjonsfil din AI-parprogrammerer faktisk leser.

Mange team skriver CLAUDE.md som en README. Det er den første feilen. En README forklarer prosjektet for mennesker som kan skumme og hoppe over. CLAUDE.md konsumeres i sin helhet av Claude Code ved øktstart, og hver linje koster tokens og etterlevelse. Det er mye nærmere en konfigurasjonsfil eller et sett testfiksturer enn dokumentasjon.

Det er heller ikke den eneste måten å styre Claude på. Hooks kjører deterministiske handlinger (formatering, blokkering av commits). Skills pakker gjenbrukbare arbeidsflyter. CLAUDE.md sitter i mellom som rådgivende kontekst — Claude evaluerer den, overstyrer den av og til, og glemmer definitivt deler av den hvis du skriver for mye. Det skillet er grunnlaget for alt nedenfor, og det er grunnen til at CLAUDE.md er ett verktøy i den bredere praksisen med context engineering, ikke en universalløsning.

Regel 1: Behandle den som kode, ikke dokumentasjon. Versjonshandle den. Gjennomgå den i PR-er. Kutt den slik du ville refaktorert et oppblåst modul. Ifølge Anthropics CLAUDE.md-guide lastes filen med samme prioritet som enhver systeminstruksjon — noe som betyr at en foreldet regel fra seks måneder siden fortsatt aktivt former hvert svar i dag.

Hvordan CLAUDE.md lastes: 4-nivåhierarkiet

Kort sagt: Claude Code laster CLAUDE.md fra fire nivåer: global (~/.claude/CLAUDE.md), prosjektrot, CLAUDE.local.md for personlige overstyringer, og undermappefiler som laster lat — bare når Claude leser filer inne i den mappen. Søskenundermapper ser aldri hverandres CLAUDE.md, noe som holder claude code-minnet stramt avgrenset.

Hierarkiet er den ene mest misforståtte delen av CLAUDE.md, og det er der ingen av de 5 beste SERP-resultatene går i dybden. Her er hva som faktisk skjer under panseret:

To begreper verdt å feste seg ved: lat lasting og søskenisolasjon.

Lat lasting betyr at en undermappe-CLAUDE.md ikke trer inn i Claudes kontekst før Claude faktisk åpner en fil i den mappen. Hvis du spør «fiks påloggingsbuggen» og Claude bare berører backend/, lastes aldri frontend/CLAUDE.md. Dette er bra — det holder kontekstvinduet rent — men det biter team som legger kritiske regler i undermapper og forventer at de alltid gjelder.

Søskenisolasjon er konsekvensen: frontend/CLAUDE.md og backend/CLAUDE.md laster aldri hverandre. De deler bare det som er i prosjektroten. Så hvis frontend-reglene dine motstrider backend-reglene, er det greit. Hvis de trenger å dele en konvensjon, skyv den opp til rotfilen.

CLAUDE.local.md er nødutgangen. Den lastes men committes ikke, perfekt for «Jeg foretrekker pnpm men teamet standardiserte på npm»-typen av overstyringer. Fallgruven: den gitignoreres ikke automatisk. Du må legge den til selv. Glemmer du det, committer du dine personlige regler inn i teamets repo.

Regel 4: Match instruksjoner til der Claude faktisk leser dem. Stilregler for React-komponenter hører hjemme i frontend/CLAUDE.md, ikke i roten. Regler for databasemigreringer hører hjemme i backend/. Anthropics Memory-dokumentasjon (oppdatert november 2025) bekrefter dette — den late lastingen er tilsiktet og lastebærende.

Hva du skal legge i CLAUDE.md (og hva du skal la være)

Kort sagt: I CLAUDE.md går alt Claude ikke kan utlede fra koden din: build-kommandoer, navnekonvensjoner, anti-mønstre teamet har brent seg på, og hvorfor bak hver regel. Utenfor går alt i README, alt i package.json, og enhver regel som endres ukentlig. claude code-instruksjoner bør være testbare og spesifikke.

Her er en minimal CLAUDE.md som faktisk bærer vekt:

# Project: techsy-app

## Commands
- Build: `pnpm build` (Turbopack — Webpack flags don't apply)
- Test: `pnpm test --run` (we use Vitest, not Jest)
- Lint: `pnpm lint` (will fail CI on warnings, not just errors)

## Conventions
- Server components by default. Add `'use client'` only when truly needed.
  Why: we hit 8s LCP last quarter from over-clienting.
- Database access only via `lib/db/` helpers — never raw SQL in routes.
  Why: row-level security policies live in those helpers.
- Tests colocate as `*.test.ts` next to the file under test.

## Don'ts
- Don't add a new dependency without opening a PR comment first.
- Don't use `any` — use `unknown` and narrow.

## Where to look
- Schema: `db/schema.ts`
- Auth flow: `lib/auth/README.md`

Sammenlign det med anti-mønsterversjonen de fleste team leverer:

# Project Rules

- Write clean, maintainable code.
- Follow best practices.
- Use TypeScript properly.
- Make sure tests pass.
- Be consistent with existing patterns.
- Document complex logic.

Den andre filen er ikke feil. Den er bare ubrukelig. Claude vil allerede skrive ren kode. «Vær konsistent» forteller ikke Claude hvilket mønster den skal være konsistent med. Anthropic-ingeniør Boris Chernys offentlige eksempler lener seg hardt mot den første stilen — konkrete kommandoer, navngitte verktøy, og hvorfor bak beslutninger som ikke er åpenbare fra kodebasen alene.

Regel 2: Vær spesifikk, ikke aspirerende. «Skriv ren kode» er aspirerende. «Server components by default; legg til 'use client' bare når det virkelig er nødvendig» er testbart. Den samme disiplinen ligger bak god prompt engineering: spesifikke, testbare instruksjoner slår vage ambisjoner, enten de bor i en prompt eller en CLAUDE.md.

Regel 3: Forklar hvorfor hver regel betyr noe. «Hvorfor» er ikke fyll — det er slik Claude avgjør kanttilfeller. En regel med en begrunnelse («vi traff 8s LCP fra over-clienting») generaliserer til lignende situasjoner. En regel uten begrunnelse ignoreres i det øyeblikk konteksten skifter. Mønsteret er også dokumentert i Builder.ios CLAUDE.md-guide.

Hvorfor ignorerer Claude CLAUDE.md? Instruksjonsbudsjettet

Kort sagt: Claude er ikke ond — den løper ut av oppmerksomhet. Forbi omtrent 80 linjer begynner regler å droppe; forbi 200 linjer ignoreres store blokker helt; forbi 500 ord med tette regler kollapser etterlevelsen. Løsningen er et instruksjonsbudsjett. Behandle hver linje som en kostnad på claude code-minnet og etterlevelse per regel.

Nyere forskning bekrefter hva produksjonsbrukere stadig finner: instruksjonsoppfølging forverres ikke-lineært med antall regler. Arxiv-artikkelen 2507.11538 om instruksjonskapasitet viser at etterlevelse per regel synker når du stabler opp flere — og HumanLayers analyse av CLAUDE.md i produksjon gjenspeiler det samme funnet.

Oversatt: hver regel du legger til gjør at alle andre regler blir litt mindre sannsynlig å bli fulgt. Så en 400-linjers CLAUDE.md er ikke 4 ganger så effektiv som en på 100 linjer. Den er ofte mindre effektiv, fordi reglene du faktisk bryr deg om fortynnes av de du skrev en fredag for tre måneder siden og aldri slettet.

I våre CLAUDE.md-filer begynner alt forbi linje 150 å miste etterlevelse synlig. Innen linje 250 har vi sett Claude hoppe over hele seksjoner. Så vi setter tak.

wc -l CLAUDE.md

Det er hele verktøyet. Kjør det. Er du over 200, er du over budsjettet. Den harde regelen vi leverer til klienter:

Behandle CLAUDE.md som et 200-linjers budsjett. Hver linje koster etterlevelse. Bruk det der det betyr noe.

Regel 1 forsterket: Hold den kort. Under 200 linjer. Under 500 ord med tette regler. Hvis du ønsker å legge til automatiseringsregler («kjør alltid prettier etter redigering»), hører de sannsynligvis hjemme i Claude Code hooks i stedet — hooks er deterministiske og koster ikke instruksjonsbudsjett-tokens.

Skal du bruke CLAUDE.md, AGENTS.md, .cursorrules eller copilot-instructions?

Kort sagt: Hvis du bare bruker Claude Code, er CLAUDE.md greit. Hvis du bruker to eller flere agent-CLI-er (Codex, Cursor, Copilot, Sourcegraph), bytt til AGENTS.md og symlink CLAUDE.md til AGENTS.md. AGENTS.md dukket opp sent i 2025 som en kryssverktøy-standard — de fleste moderne agenter faller tilbake til den, så én fil mater hele økosystemet.

Dette er spørsmålet ingen av de 5 beste resultatene faktisk svarer på. Her er matrisen:

Dobbeltmål-trikset er én linje:

ln -s AGENTS.md CLAUDE.md

Det er alt. Nå leser Claude Code, Codex og ethvert AGENTS.md-bevisst verktøy den samme filen. Oppdater én gang, og hver agent plukker den opp. AGENTS.md-spesifikasjonen er åpen og bevisst minimal — det er bare markdown med konvensjonelle seksjoner.

To reelle forviklinger. For det første: hvis teamet ditt har en Cursor-kraftbruker, tar Cursors .cursorrules en annen tilnærming — én fil, ingen hierarki, mer rigid format. Noen team beholder begge: AGENTS.md for de delte reglene, .cursorrules for Cursor-spesifikke særheter. For det andre: Copilots .github/copilot-instructions.md faller ikke tilbake til AGENTS.md, så Copilot-tunge team trenger en egen fil.

Hvis du velger en agent-stack fra bunnen av, dekker vår Claude Code vs Cursor vs Copilot-sammenligning avveiningene på harness-nivå. Kortversjonen: Claude Codes hierarki er det kraftigste for monorepos, Cursors UX vinner for soloarbeid, Copilots IDE-integrasjon er fortsatt den mest sømløse for inkrementell adopsjon.

Regel 9: Bruk AGENTS.md hvis du kjører mer enn én agent-CLI. Ikke vedlikehold to filer som sier det samme. Velg filen de fleste i stacken din leser, og symlink resten.

CLAUDE.md vs hooks vs skills: Beslutningstriangelet

Kort sagt: CLAUDE.md = rådgivende kontekst. Hooks = deterministiske handlinger. Skills = pakkede muligheter. Velg feil, og du brenner instruksjonsbudsjett på noe en hook burde håndtere, eller skriver en CLAUDE.md-regel for noe bare en skill kan levere. Triangelet er den billigste måten å holde CLAUDE.md slank.

Tre verktøy, tre jobber. Feilen vi ser oftest: å legge «kjør alltid prettier etter redigering» i CLAUDE.md. Claude leser det. Claude kjører noen ganger prettier. Du er frustrert. Løsningen er å flytte den linjen ut av CLAUDE.md og inn i en hook — fordi hooks utløses deterministisk hver gang, uten rådgivende rom for skjønn.

Hvis en regel alltid må utløses, hører den hjemme i en hook. Hvis det er en stilpreferanse Claude kan evaluere mot kontekst, hører den hjemme i CLAUDE.md. Hvis det er en flertrinnsprosess med pakkede ressurser (maler, skript, prompter), hører den hjemme i en skill.

Regel 8: Velg riktig mellom CLAUDE.md, hooks og skills — å legge en hook i CLAUDE.md er den vanligste sløsingen av instruksjonsbudsjett. Konfigurer deterministiske handlinger med Claude Code hooks og pakk gjenbrukbare arbeidsflyter som Claude skills. CLAUDE.md blir kortere, sikkerhetsnettene dine blir sterkere, og Claude slutter å «glemme» reglene som betyr noe.

Monorepo-mønstre: Nestet CLAUDE.md, @imports og .claude/rules/

Kort sagt: I et monorepo holder du rot-CLAUDE.md liten — bare pekere og delte konvensjoner. Skyv spesifikke ting inn i apps/*/CLAUDE.md så hvert deltre har avgrensede regler. Bruk @imports til å dele modulære regelfiler via .claude/rules/. Dette er progressiv avsløring — Claude henter hvert stykke bare når det er relevant.

Et typisk CLAUDE.md-tre for monorepo:

.
├── CLAUDE.md                        # 30 linjer — peker til undermapper og delte regler
├── .claude/
│   └── rules/
│       ├── style.md
│       ├── testing.md
│       └── security.md
├── apps/
│   ├── web/
│   │   └── CLAUDE.md                # Next.js-spesifikke regler
│   └── api/
│       └── CLAUDE.md                # Fastify-spesifikke regler
└── packages/
    └── shared/
        └── CLAUDE.md                # Biblioteksforfatterregler

@import-syntaksen lar rotfilen hente inn delte regelstykker uten å gjenta dem:

# Root CLAUDE.md

This is a Turborepo. See subdir CLAUDE.md for app-specific rules.

@import .claude/rules/style.md
@import .claude/rules/testing.md
@import .claude/rules/security.md

## Top-level commands
- `pnpm dev` runs all apps in parallel
- `pnpm test` runs every workspace's test script

Dette er progressiv avsløring i praksis. Rotfilen er en 30-linjers peker. Hver undermappe-CLAUDE.md legger til 50–80 linjer med fokuserte regler. .claude/rules/-filene inneholder konvensjonstykker som flere undermapper kan hente. Ingenting er duplisert, ingenting er mistet, og ingen enkelt fil overskrider instruksjonsbudsjettet.

Den late lastingsregelen fra tidligere betyr enda mer her: når Claude arbeider på apps/web/Button.tsx, ser den rotfilen pluss apps/web/CLAUDE.md pluss de @import-ede regelfilene. Den ser ikke apps/api/CLAUDE.md. Det er hele poenget — backend-konvensjoner forurenser ikke frontend-kontekst, og kontekstvinduet forblir brukbart.

Regel 6: Bruk @imports til å holde rotfilen under 200 linjer. Anthropics beste praksiser for Claude Code behandler dette som standard monorepo-mønster. Subagenter arver overordnet CLAUDE.md-kontekst også, noe som er verdt å vite hvis du nester arbeidsflyter — se context engineering for hvordan det samvirker med subagent-design.

6 grunner til at Claude ignorerer filen din (og løsningen på hver)

Kort sagt: Når Claude ignorerer CLAUDE.md, er det nesten alltid én av seks årsaker: filen er for lang, vage formuleringer, manglende «hvorfor», kontekstkomprimering, motstridende overordnet fil, eller feil filnavn. Hver har en 60-sekunders løsning. Test i en ny økt etter hver endring — det er Regel 7.

1. Filen er for lang (>200 linjer / >500 ord)

Kjør wc -l CLAUDE.md. Er den over 200, kutt aggressivt. Flytt automatiseringsregler til hooks. Flytt arbeidsflyter til skills. Del delte stykker inn i .claude/rules/ og hent dem med @import. Den vanligste grunnen til at Claude «sluttet å følge» reglene dine er at filen ble for lang over tid og etterlevelsen stille kollapset.

2. Vage formuleringer («skriv ren kode»)

Erstatt hver aspirerende regel med en spesifikk, testbar en. «Vær konsistent» er usynlig for Claude. «Bruk server components som standard; legg bare til 'use client' for skjemaer eller interaktivt UI» er noe Claude faktisk kan anvende.

3. Manglende «hvorfor»

Regler uten begrunnelser generaliserer ikke. Claude kan ikke utlede når regelen kan bøyes fordi den ikke vet hva regelen beskytter mot. Hver ikke-åpenbar regel får en enlinje: «vi bruker unknown og ikke any fordi vi hadde tre kjøretidskrasj fra typed-as-any API-responser forrige kvartal.»

4. Kontekstkomprimering slettet den

Lange økter utløser komprimering — Claude oppsummerer tidligere kontekst for å få plass i vinduet, og CLAUDE.md-innhold blir noen ganger oppsummert til ingenting. Løsningen: /clear etter store kontekstbranner, eller start økten på nytt. Dette er nøyaktig hva GitHub Issue #17530 stadig avdekker.

5. Motstridende overordnet CLAUDE.md

Global sier «bruk 4 mellomrom.» Prosjektrot sier «bruk 2 mellomrom.» Undermappe sier ingenting. Claude velger én — noen ganger feil. Revider ~/.claude/CLAUDE.md og prosjektroten for motsetninger. Den som er mer spesifikk bør vinne, men bare hvis du gjør det eksplisitt.

6. Feil filplassering eller filnavnets store/små bokstaver

Claude.md og CLAUDE.md er forskjellige filer på Linux og macOS. Det er også claude.md og CLAUDE.md. Bekreft at stien er nøyaktig ./CLAUDE.md (bare store bokstaver), og at Claude Code startes fra mappen som inneholder den. GitHub Issue #668 er full av tilfeller der filen eksisterte men Claude ikke kunne se den på grunn av stier.

Regel 7: Test i en ny økt. Etter en CLAUDE.md-endring, åpne en ny økt og be Claude om å «oppsummere reglene i CLAUDE.md». Hvis oppsummeringen mangler noe, gjør ikke filen jobben sin.

Din første CLAUDE.md på 10 minutter: En oppskrift i 5 trinn

Kort sagt: Kjør /init for å starte et utkast, trim det til 6–10 ekte regler med begrunnelser, legg til 3 kommandoer Claude bør kjenne til, legg til 2 anti-mønstre teamet ditt har støtt på, og test deretter i en ny økt ved å be Claude oppsummere filen. Total tid: omtrent 10 minutter. 5-trinnsoppskriften bruker vi på dag 1 i alle nye repoer.

1. Kjør /init for å starte et utkast. Claude Codes /init-kommando skanner repoet ditt og skriver en starter-CLAUDE.md. Ikke lever det den skriver. /init-output er et utgangspunkt, ikke en ferdig fil — og ærlig talt kan det meste av det som genereres fjernes.

2. Trim det til 6–10 linjer med faktiske regler med begrunnelser. Slett alt generisk. Slett alt som er i README. Behold bare regler Claude ikke kan utlede fra koden selv.

3. Legg til 3 kommandoer Claude bør kjenne til. Build, test, lint. Inkluder den eksakte kommandoen og eventuelle ikke-åpenbare flagg. Hvis du bruker Vitest og ikke Jest, si det.

4. Legg til 2 anti-mønstre dette teamet har truffet. Ekte ones. «Ikke bruk any fordi vi hadde tre kjøretidskrasj» slår «bruk TypeScript riktig» hver gang.

5. Åpne en ny økt og verifiser. Be Claude om å «oppsummere reglene i CLAUDE.md». Mangler noe, er filen for lang, for vag, eller mangler en «hvorfor». Fiks og gjenta.

Regel 5: Ikke autogenerer fra /init alene. /init er et utgangspunkt, ikke en ferdig fil. De 8 minuttene du bruker på å trimme den er der verdien ligger.

Vanlige spørsmål

Hva er en CLAUDE.md-fil?

En CLAUDE.md-fil er en markdown-fil Claude Code leser som prosjektminne ved starten av hver økt. Den forteller Claude konvensjonene, kommandoene og anti-mønstrene dine slik at den slipper å gjette. Den fungerer på fire nivåer: global, prosjektrot, undermappe (lat-lastet) og en personlig CLAUDE.local.md du holder gitignorert.

Hvor lang bør en CLAUDE.md-fil være?

Under 200 linjer og under 500 ord med tette regler. Forbi disse tersklene forverres Claudes instruksjonsoppfølging — hver regel du legger til gjør at alle andre regler blir litt mindre sannsynlig å bli fulgt. Behandle den som et fast budsjett. Trenger du mer, del opp i undermappe-CLAUDE.md-filer og bruk @import for delte stykker.

Hvor skal jeg legge CLAUDE.md?

Hoved-CLAUDE.md går i prosjektroten (./CLAUDE.md) og committes. Legg til undermappe-CLAUDE.md-filer for app-spesifikke regler i monorepos. Legg kryssprosjekt-preferanser i ~/.claude/CLAUDE.md. Bruk CLAUDE.local.md for personlige overstyringer du ikke vil committe — men husk å gitignorere den manuelt.

Hvorfor ignorerer Claude CLAUDE.md-filen min?

90 % av gangene er det én av tre ting: filen er for lang (over 200 linjer), reglene er vage («skriv ren kode»), eller regler mangler et «hvorfor» Claude kan bruke til å anvende dem. Kjør wc -l CLAUDE.md, og revider deretter for spesifisitet. Test endringer i en ny økt ved å be Claude oppsummere filen.

Skal jeg bruke CLAUDE.md eller AGENTS.md?

Hvis teamet ditt bare bruker Claude Code, hold deg til CLAUDE.md. Hvis du bruker to eller flere agent-CLI-er (Codex, Cursor, Sourcegraph), bytt til AGENTS.md og symlink CLAUDE.md til den: ln -s AGENTS.md CLAUDE.md. De fleste moderne agent-CLI-er faller tilbake til AGENTS.md, så én fil mater alle verktøy.

Skal jeg kjøre /init for å generere CLAUDE.md?

Ja — som et utkast. Nei — som en ferdig fil. /init skanner repoet ditt og lager en starter, men den er ordrik og generisk. Både Anthropic og HumanLayer anbefaler å klippe aggressivt etter å ha kjørt /init. De 8 minuttene du bruker på å kutte og legge til «hvorfor»-linjer er der filen faktisk blir nyttig.

Hvordan fungerer CLAUDE.md-filer i et monorepo?

Rot-CLAUDE.md forblir liten — bare pekere og delte regler. Hver app får sin egen apps/*/CLAUDE.md med avgrensede konvensjoner. Undermappefiler lastes lat bare når Claude leser filer i det deltreet, så søsken forblir isolert. Bruk @import .claude/rules/style.md for å dele modulære regelstykker uten å duplisere dem på tvers av apper.

Hva er forskjellen mellom CLAUDE.md, hooks og skills?

CLAUDE.md er rådgivende kontekst — Claude leser den og følger den som oftest. Hooks er deterministiske handlinger som alltid utløses (formatering, blokkering av commits). Skills er pakkede muligheter for gjenbrukbare arbeidsflyter med ressurser. Bruk CLAUDE.md for stilretningslinjer, hooks for harde regler, og skills for flertrinnsoppgaver du vil gjenta på tvers av prosjekter.

Slik tilnærmer Techsy seg dette

Hos Techsy har alle Claude Code-prosjekter vi leverer en CLAUDE.md under 150 linjer og en AGENTS.md-symlink. Vi behandler filen som kode — versjonshandler den, gjennomgår endringer i PR-er, og re-tester i nye økter før merge. Trenger du hjelp med å koble AI-agenter inn i utviklingsarbeidsflyten din? Få en gratis konsultasjon.