Slik setter du opp CLAUDE.md i 2026: Mal og 6 regler

Materiell om vibe coding: verktøy, casestudier, feil. Ailoot-veiledninger.

Hvorfor trenger du CLAUDE.md, og hvorfor glemmer Claude prosjektet uten den?#

Du åpner Claude Code på tirsdag og forklarer: «Jeg jobber med dette prosjektet, dette er verktøyene, ikke gjør dette.» Det fungerer.

På torsdag er den samme chatten allerede avsluttet, så du gjentar alt. På lørdag, igjen; på mandag, enda en gang.

Slik ser det ut å jobbe med en agent uten CLAUDE.md: hvert nytt vindu er en praktikant med blanke ark som du må fortelle de samme tingene om og om igjen. Før brukte jeg 5-10 minutter på å skrive denne oppvarmingen i hver økt. Ledetekstene ble lange fordi jeg måtte bære all konteksten manuelt. Og resultatet var fortsatt generisk: agenten kjente ikke målgruppen min, økonomien min eller prinsippene mine.

Med en levende CLAUDE.md forsvinner oppvarmingen. Alle reglene du pleide å gjenta i hver chat, ligger i én fil og vises automatisk ved starten av hver økt. Ledeteksten blir kort: «gjør X», i stedet for «jeg jobber med prosjekt Y, verktøyene er Z, ikke gjør A eller B, og forresten, husk også C».

Da forsvinner de gjentatte feilene.

Hver agentfeil er en grunn til å legge til én linje i CLAUDE.md. Etter en måned har du en levende «prosjektgrunnlov», og Claude slutter å gå i de samme velkjente fellene.

Og så er det et tredje lag: agenten slutter å skrive i et vakuum. Gjennom CLAUDE.md ruter jeg Claude til mapper med kontekst: hvor den skal lete etter informasjon om målgruppen, priser og merkevarebygging. Uten denne rutingen skriver agenten «løsninger av høy kvalitet» uten å kjenne økonomien min, og resultatet blir abstrakt, formelpreget og «akkurat som alle andres».

Hva er CLAUDE.md, og i hvilken rekkefølge leser Claude den?#

Anthropic beskriver CLAUDE.md slik i den offisielle dokumentasjonen:

De fire stedene Claude Code leter etter CLAUDE.md, i stigende prioritetsrekkefølge:

Alle fire filene lastes inn i konteksten samtidig. Hvis reglene er i konflikt, sier Anthropic direkte i dokumentasjonen sin at det er ukjent hvilken regel som får forrang; Claude kan velge én av dem vilkårlig. Derfor er det enklere å samle alt kritisk i prosjektets CLAUDE.md og unngå å opprette duplikater.

Det finnes én teknisk detalj nesten ingen skriver om, men den forklarer mye merkelig atferd.

Med andre ord er CLAUDE.md ikke en «systemprompt» i streng forstand. Det er den første brukermeldingen Claude ser. Derfor er reglene sterke forslag, ikke lover. Hvis en regel må håndheves, bruker du en testet hook for hendelsen den dekker, samt tillatelser eller miljøisolasjon for den bredere tilgangsgrensen. At en hook kjøres automatisk, betyr ikke at kontrollene er fullstendige. Jeg forklarer grensen mellom hooks og CLAUDE.md nedenfor.

Hvordan skriver du en minimal CLAUDE.md på 5 minutter (ferdig mal)?#

Nedenfor er en mal jeg har testet i dusinvis av prosjektene mine. Den holder filen på rundt 80-120 linjer, innenfor Anthropics anbefaling om å sikte mot under 200 linjer. Med denne malen gir agenten de mest fornuftige resultatene.

# [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/<current plan>`,
   `mastery/<area>` 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.

For at Claude skal fylle ut denne malen for prosjektet ditt automatisk, gir du den denne ledeteksten. Den leser konteksten og fyller ut feltene i hakeparenteser:

Create a CLAUDE.md file at the project root using this template:

[INSERT THE ENTIRE TEMPLATE FROM ABOVE]

Proceed as follows:

Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author.

Fill in all the square-bracketed fields in the template based on what you find in those folders.

If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options.

Sikt mot å holde den resulterende CLAUDE.md under 200 linjer. Er den lengre, gjennomgå gjentakelser og flytt detaljerte prosedyrer til lenkede filer. Behold nødvendige regler for planlegging, refleksjon og repositoriet, og test dem deretter på representative oppgaver.

Show me the final file and ask what should be revised.

Always respond in the user’s preferred language.

Hvis du ennå ikke har mappene about-me/ og business/, går det bra. Claude stiller oppklarende spørsmål og setter sammen en minimal CLAUDE.md basert på det som finnes. Du kan opprette mappene senere, når du vet hva du skal ha i dem.

Hvilke 6 regler gjør CLAUDE.md til et levende dokument?#

Regel 1. Hold den under 200 linjer

Anthropic sier det kort og presist i den offisielle dokumentasjonen:

En lang CLAUDE.md motarbeider seg selv på to måter. For det første bruker den tokens. En fil med 800 linjer instruksjoner lastes inn i hvert vindu og bruker opp flere tusen tokens av budsjettet i hver økt. Med et Pro-abonnement og en daglig grense reduserer det merkbart antallet tilgjengelige økter. For det andre begynner modellen å ignorere reglene.

Dokumentasjonen anbefaler å sikte mot under 200 linjer for å redusere kontekstbruk og forbedre etterlevelse. Den etablerer ingen skarp feilgrense ved linje 201. Vurder relevans, motstridende regler, innlastet tokenmengde og faktiske oppgaveresultater før du flytter detaljer ut.

Regel 2. Avslutt hver økt med en refleksjon

Skriv i CLAUDE.md: «På slutten av hver økt skal du registrere hva du gjorde og lærte i retrospectives/YYYY-MM-DD_*.md.» Når du har lagt til denne linjen, begynner Claude å avslutte hver økt med en refleksjon på egen hånd; du trenger ikke å be om det.

Hvorfor reflektere:

• To uker senere kan du åpne en gammel retrospektiv og huske hvorfor du valgte den veien.
• Når du kommer tilbake til prosjektet en måned senere, har du et ferdig kart over nylige beslutninger.
• Hvis du jobber i et team, kan en kollega lese retrospektiven og forstå nåsituasjonen på 2 minutter, uten en samtale.

Regel 3. Gjør en commit etter hver fullførte oppgave

I min CLAUDE.md står det: «Etter hver fullførte oppgave skal du opprette en git-commit med en meningsfull melding.» Claude begynner da å dele arbeidet inn i atomiske commits på egen hånd.

Dette gir deg to ting. For det første kan du rulle tilbake én operasjon hvis noe går galt, i stedet for «alt jeg gjorde i dag». For det andre blir commit-historikken en arbeidslogg som viser hva som endret seg, og i hvilken rekkefølge.

Regel 4. Sjekk alltid business/-mappen

For enhver oppgave som gjelder kunder, produkter eller tekst, bør agenten først åpne business/INDEX.md og den relevante filen derfra. I min CLAUDE.md står det uttrykkelig: «Når du jobber med brukergrensesnittet eller tekst, sjekk først business/audience/avatar.md og business/assets/brand-guidelines.md.»

Uten denne regelen skriver Claude tekst i «den generelle stilen til et kvalitetsnettsted». Med den får du tekst i din stil, for kundene dine, uten ordene du har forbudt.

Regel 5. Legg til en regel etter hver agentfeil

Dette er hovedregelen som holder CLAUDE.md levende.

Eksempler fra min egen CLAUDE.md som ble lagt til etter bestemte feil:

• «Ikke commit andres WIP-filer med git add . - legg til filer ved navn.»
• «Før du pusher til main, sjekk git log origin/main..main --oneline - hvis den ikke er tom, ikke push.»
• «Ikke finn på verdier - hent dem fra .env eller koden. Særlig URL-er, brukernavn og tokens.»

Hver av disse linjene er spor etter en konkret hendelse. En gang committet en agent en partners uferdige branch. En gang inkluderte jeg andres upushte commits. En gang fant en agent på en URL som ikke finnes. Hver feil blir til en regel, og det samme selvpåførte såret oppstår ikke igjen.

Regel 6. Legg sikkerhetsreglene i .claude/settings.json, ikke CLAUDE.md

I CLAUDE.md kan du skrive «ikke rør .env», men det er en oppfordring; Claude kan bryte den fordi CLAUDE.md lastes inn som en brukermelding, ikke som en lov. For kritisk sikkerhet bruker du .claude/settings.json, der du kan blokkere bestemte kommandoer strengt.

Blokkeringslisten jeg legger til i hvert nye prosjekt:

• rm -rf (rekursiv sletting av vilkårlige filer).
• Fullstendig lesing av .env (Read .env).
• export og curl i samme kommando (et mønster for å lekke hemmeligheter eksternt).
• git push --force uten uttrykkelig godkjenning.

Finn flere veiledninger hos Ailoot.

Hvordan er CLAUDE.md strukturert i en aktiv virksomhet (anatomi av en fil på 280 linjer)?#

De fleste eksemplene på CLAUDE.md på nettet er tekniske maler for utviklere: «Bruk TypeScript», «Ikke skriv tester som er lengre enn 50 linjer». For en gründer er denne typen CLAUDE.md ubrukelig - den dekker ikke forretningssiden.

Nedenfor er strukturen i min fungerende CLAUDE.md. Jeg har fjernet de konkrete reglene og banene fordi de gjenspeiler min interne drift. Men strukturen og logikken i seksjonene kan brukes i ethvert prosjekt: legg til dine egne forhold, så får du en fungerende fil.

1. Kort prosjektbeskrivelse (15 linjer). Hva vi gjør, hvem målgruppen er, hvilke produkter vi tilbyr. Ikke en oppsummering av markedsnettstedet, men en oppsummering for agenten slik at den forstår «hvor vi er på vei».

2. Om meg (10 linjer). En pekepinn til about-me/-mappen - en digital projeksjon av hvordan jeg tenker. Tone, verdier, prinsipper, forbudte ord. Når Claude skriver tekst «som meg», leser den denne mappen først, slik at stemmen stemmer.

3. Repositoriets struktur (20 linjer). Et tre med kommentarer: hvor koden ligger, hvor forretningskonteksten finnes, hvor planer og refleksjoner ligger. Uten dette kartet leter Claude blindt etter filer hver gang.

4. Tabellen «Hvor finner du ting» (25 linjer). Ruting fra «spørsmål → fil». For eksempel kan det for et eiendomsmeglerfirma stå «trenger boliglånsvilkår → business/products/mortgage.md» eller «trenger tonen for innlegg → business/assets/voice.md». Bytt ut med dine egne filer. Denne tabellen er kjernen i CLAUDE.md. Uten den gjetter agenten hvilken fil som inneholder svaret. Med den går den rett til kilden.

5. Viktige prosjektprinsipper (40 linjer, 10-15 punkter). Denne seksjonen bygges opp gradvis og krever mest innsats. Hvert punkt er spor etter en konkret feil. For en nettbutikk kan reglene for eksempel være «hardkod aldri priser og leveringstider», «ikke publiser et produkt uten en uttrykkelig kommando» og «sjekk stilen mot merkevareordlisten før du publiserer en produktoppføring». Denne seksjonen er «prosjektgrunnloven».

6. Operasjonell planlegging (20 linjer). En utløsende tabell som kobler «brukeruttrykk → handling». For eksempel: «Når jeg sier ‘planlegg uken’, åpne ops/monthly.md og opprett ukens fil.» Dette gjør Claude til en driftsassistent som forstår konteksten for kommandoer.

7. Verktøy (5 linjer). Teknologier. Kortfattet, uten fyll.

8. Publisering (15 linjer). En trinnvis prosess for å publisere endringer til produksjon: hvilke kommandoer som skal kjøres, i hvilken rekkefølge, og hva som skal kontrolleres. Før forklarte jeg det hver gang. Nå vet Claude det.

9-12. Sikkerhet (35 linjer). Fire separate underseksjoner: regler for arbeid med .env, tilgang til produksjonsdatabasen, sikre kommandoer for demoer (skjermopptak, strømminger, skjermbilder, slik at tokens ikke eksponeres ved et uhell) og regler for å rotere hemmeligheter.

13. plans/-mappen (10 linjer). Planstandarden: filnavn, fasestruktur og hva som skal stå i oppsummeringsblokken.

14. retrospectives/-mappen (5 linjer). Refleksjonsstandarden: mal, filnavn og hva den skal inneholde.

15. Data fra den aktive databasen (15 linjer). En regel for å merke «ferske data»: når en fil sier at tallene må være oppdaterte, henter agenten dem fra kilden i stedet for å bruke gamle tall. Dette fjerner risikoen for at Claude bruker gårsdagens tall.

16. Språk (3 linjer). «Svar alltid på brukerens foretrukne språk. Bruk bare bindestreker, ikke em-dash.»

Omtrent 280 linjer totalt. Det overskrider målet om korthet, men gjør ikke filen ugyldig. I dette eksemplet var den fortsatt nyttig. Om den bør beholdes, må avgjøres med målt kontekstbruk og representative oppgavetester. Tabeller bruker ikke automatisk færre tokens enn løpende tekst.

Hva gjør kommandoen /init, og hvorfor er den ikke nok?#

Anthropic beskriver kommandoen slik i dokumentasjonen sin:

Dette gjør /init bra:

• Identifiserer verktøyene fra package.json, Cargo.toml og pyproject.toml.
• Lister opp bygge- og testkommandoer.
• Fanger opp konvensjoner fra eksisterende filer (.eslintrc, .prettierrc).
• Oppdager eksisterende Cursor-regler (.cursorrules, .cursor/rules/) og Copilot-regler og tar med relevante deler. Den fanger opp AGENTS.md i modusen CLAUDE_CODE_NEW_INIT=1.

Dette gjør /init ikke:

• Den vet ikke hvem kunden din er.
• Den inkluderer ikke forbudte ord for tekst.
• Den legger ikke til regler om agentfeil (fordi det ikke har vært noen ennå).
• Den oppretter ikke en «hvor finner du ting»-tabell for virksomhetsstrukturen din.

Den riktige arbeidsflyten er derfor:

1. Kjør /init i Claude Code

   Du får en startfil for CLAUDE.md på 30-50 linjer med verktøy og kommandoer. Dette er det tekniske fundamentet.

2. Legg malen fra denne artikkelen oppå

   Bruk seksjonen «En minimal CLAUDE.md på 5 minutter». Legg til seksjoner for navigasjon, ruting og prinsipper.

3. Fyll ut feltene i hakeparenteser

   Gi Claude ledeteksten «les prosjektet mitt og fyll ut malen». Hvis mappene business/ og about-me/ ikke finnes ennå, vil Claude stille oppklarende spørsmål.

4. Kjør en stresstest

   Be Claude: «Les CLAUDE.md og finn 10 uklarheter som kan få deg som agent til å misforstå.» Du får en liste med forbedringer.

5. Bruk så filen i praksis

   Legg til en linje etter hver agentfeil. Etter en måned har du en levende CLAUDE.md tilpasset virksomheten din.

Ledetekst for steg fire:

I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it.

Your task is to stress-test it. Find 10 reasons we could potentially fail:

where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it

where there are gaps that would force you to make things up

where rules contradict one another

where I overestimate how much can be done in one day

where I underestimate things (this is even worse)

Don’t hold back. Criticize it harshly. I want to find these issues now, not in production.
At the end, give me a list of specific changes: what to change and how, so these problems don’t happen.

CLAUDE.md vs. AGENTS.md vs. MEMORY.md: hvem leser hva i 2026?#

Hovedspørsmålet som forvirrer nybegynnere, er: leser Claude Code AGENTS.md? Før september 2026 var svaret «nei»: Anthropics dokumentasjon anbefalte å opprette en CLAUDE.md som importerer AGENTS.md. Siden versjon 2.1.277 (utgitt 18. september 2026) leser Claude Code AGENTS.md selv, men bare hvis det ikke finnes en CLAUDE.md, .claude/CLAUDE.md eller CLAUDE.local.md i arbeidsmappen eller over den.

Hvis prosjektet har en CLAUDE.md, leser Claude Code bare den som standard og hopper over AGENTS.md. Du kan endre dette i /config, under Project instructions: for eksempel gjør innstillingen claude-md-and-agents-md at begge filene leses. En annen metode fungerer i alle versjoner: legg til en import i CLAUDE.md:

@AGENTS.md

## Claude Code

Additional rules for Claude Code that other agents don’t need.

Syntaksen @filename importerer en annen fil. Claude leser den og laster den inn i konteksten sammen med CLAUDE.md. Importen gjør ikke at filen leses to ganger, selv om Claude Code kan lese AGENTS.md på egen hånd.

Når trenger du AGENTS.md? Hvis du jobber parallelt med Claude Code og Codex CLI, Cursor eller Copilot, oppretter du en AGENTS.md som eneste sannhetskilde, legger @AGENTS.md i CLAUDE.md og legger eventuelle Claude-spesifikke regler oppå. Hvis det ikke finnes slike regler, trenger du ikke å opprette CLAUDE.md: siden versjon 2.1.277 leser Claude Code AGENTS.md selv. Hvis du bare jobber i Claude Code, trenger du ikke AGENTS.md; bruk bare én CLAUDE.md. Se veiledningen om å bruke AGENTS.md og CLAUDE.md i ett prosjekt for alle alternativene trinn for trinn.

Hva er MEMORY.md? Etter en nylig oppdatering lagrer Claude Code automatisk notater om deg i ~/.claude/projects/<project-name>/memory/MEMORY.md. Disse omfatter samtalevaner («brukeren foretrekker korte svar»), tilbakevendende uttrykk («forbød emojier i kode») og observasjoner om atferd («jobber på macOS, bruker zsh»).

Dette er et separat minnesystem, ikke CLAUDE.md. Du skriver det ikke for hånd; Claude gjør det basert på samtalene deres. Hvis MEMORY.md inneholder noe som bør bli en regel, flytter du det til CLAUDE.md. Hvis det inneholder noe unødvendig eller feil, kan du slette det manuelt; det er en tekstfil.

Hva er en nyttig størrelse på CLAUDE.md, og hvordan vurderer du en lang fil?#

I hvert Claude Code-vindu lastes flere lag inn i konteksten: Anthropics systemprompt (anslått til titusenvis av tokens), CLAUDE.md-en din, filer importert med @, MEMORY.md, den nåværende chatloggen og innholdet i filer Claude åpner. Alt dette må få plass i modellens kontekst (200K tokens for Sonnet, 1M for Opus).

Jo større CLAUDE.md blir, desto mindre plass er det til det aktuelle arbeidet. En fil på 1 000 linjer er omtrent 8 000 tokens, gjentatt i hver økt. Med et Pro-abonnement (etter min erfaring rundt 10-12 «tunge» ledetekster om dagen) reduserer det kapasiteten din med en fjerdedel.

Kostnaden er bare én bekymring. Etterlevelsen kan bli dårligere når instruksjonene er lange, irrelevante eller motstridende. Det finnes ikke et universelt antall instrukser som følges pålitelig. Test representative oppgaver som utløser kritiske regler, registrer feil og sammenlign atferden etter en avgrenset redigering.

Her er derfor en tommelfingerregel for størrelse:

• 80-120 linjer - et praktisk startområde for et kort prosjektkart, ingen garantert etterlevelsesscore.
• 150-200 linjer - et nyttig signal om å gjennomgå relevans og flytte detaljerte prosedyrer til lenkede filer.
• 200-300 linjer - undersøk tokenmengde, gjentakelser og oppgaveresultater; virksomhetseksemplet med 280 linjer ovenfor kan fortsatt fungere godt.
• 400+ linjer - en sterk grunn til en målrettet gjennomgang, ikke bevis for at filen er ubrukelig. Behold nødvendige begrensninger, og flytt detaljer først etter å ha kontrollert at lenker og regler virker.

Linjetall alene kan ikke fastslå om filen lykkes eller feiler. Gjenta de samme representative oppgavene etter redigering, og kontroller viktige regler fremfor å tilordne en oppdiktet etterlevelsesprosent.

Anthropic gir en direkte test i dokumentasjonen sin:

Bruk dette på hver linje. Hvis svaret er «den ville fortsatt gjort det riktig», fjern linjen. CLAUDE.md er ikke stedet for dokumentasjon, beslutningshistorikk eller filosofi. Den er bare for reglene agenten trenger for å unngå å rote det til.

Hvilke 7 feil gjør CLAUDE.md ubrukelig?#

Feil 1. «Vær en god ingeniør»

Den vanligste feilen. Folk skriver generelle ønsker i CLAUDE.md: «skriv ren kode», «bruk beste praksis», «tenk som en senioringeniør».

Disse ordene betyr ingenting. Claude skriver allerede «ren kode» i generell forstand. Disse linjene tar opp kontekst uten å påvirke noen beslutning.

Bytt ut «skriv ren kode» med «bruk innrykk på 2 mellomrom», «ikke bruk any i TypeScript» eller «funksjoner skal ikke være lengre enn 30 linjer». Konkret og etterprøvbart.

Feil 2. Å gjenta det Claude allerede kan

Beskrivelser av standardkonvensjoner for språk («i JavaScript er funksjoner førsteklasses objekter», «TypeScript har statisk typing»). Forklaringer på hvordan npm, git eller docker fungerer.

Claude lærte alt dette under trening. Å gjenta det i CLAUDE.md tilfører ingenting; det spiser bare av konteksten din.

Feil 3. Lange trinnvise instruksjoner i CLAUDE.md

Lange instruksjoner om «hvordan prosjektet skal distribueres», «hvordan en databasemigrering skal skrives» eller «hvordan en ny komponent skal settes opp». Flere titalls trinnvise linjer.

Dette er ikke stedet for lange trinnvise instruksjoner. Den er for regler på én linje. Legg lange instruksjoner i skills/ (en separat Claude Code-mekanisme som lastes inn ved behov) eller i docs/. Bruk en lenke på én linje i CLAUDE.md: «Når du oppretter en ny migrering, åpne docs/migrations.md.»

Feil 4. Regler som allerede kontrolleres av en automatisk kodeanalysator

«Bruk semikolon», «ikke la ubrukte importer stå igjen», «ikke bruk var». ESLint, Prettier og Biome fanger opp alt dette - de er linters (verktøy for automatisk kodesjekk).

En linter er deterministisk: den kjører, finner en feil og retter den. En regel i CLAUDE.md er probabilistisk; agenten kan glemme den. Det er ingen grunn til å gjenta den - det er enklere å konfigurere linteren.

Feil 5. Hemmeligheter i CLAUDE.md

Jeg har sett passord til testkontoer, API-tokens for sandkasser og lenker til autentiserte administrasjonspaneler. Alt lå i en fil som var lagt inn i git og lastet inn i Anthropics modellkontekst.

Aldri. Hemmeligheter hører hjemme i .env, som ligger i .gitignore. I høyden bør CLAUDE.md si: «Ikke les .env i sin helhet; bruk grep for en bestemt variabel.»

Feil 6. En søppelfil på 500+ linjer som ikke er ryddet på seks måneder

CLAUDE.md har vokst, dupliserer halve docs/, motsier seg selv flere steder, og ingen husker hva som står i den. Agenten begynner å ignorere det meste. Teamet klager over at «Claude ikke følger instruksjoner» og legger til flere regler, noe som gjør ting verre.

Tegn på en forsømt CLAUDE.md: mer enn 300 linjer, gjentatte regler i ulike seksjoner, utdaterte lenker til filer som ikke lenger finnes, og «historiske» notater som «i 2024 bestemte vi oss for å gjøre det på denne måten, og så ombestemte vi oss».

Løsningen: annenhver uke ber du Claude gå gjennom den med Anthropics test: «Hvis denne linjen ble fjernet, ville agenten gjort en feil?» Slett alt der svaret er «nei».

Feil 7. CLAUDE.md blir opprettet og glemt

Dette er det motsatte av forrige feil. Filen ble satt sammen én gang for to måneder siden, og har ikke blitt rørt siden. I mellomtiden har verktøyene endret seg, nye mapper er lagt til, og nye agentfeil har dukket opp. CLAUDE.md kjenner ikke til noe av dette fordi ingen har oppdatert den.

Et tydelig tegn: Du gjentar den samme instruksjonen i hver økt. «Ikke gjør X», «ikke rør Y», «husk Z». Hvis du har gjentatt det mer enn to ganger, hører regelen hjemme i CLAUDE.md, ikke i hodet ditt.

Hvordan gjør du CLAUDE.md selvlærende med regelen «oppdater på slutten av økten»?#

CLAUDE.md har en kort seksjon:

## 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.

Etter at denne seksjonen ble lagt til i CLAUDE.md, begynte Claude på slutten av hver økt å spørre: «Var det noe nytt som var verdt å notere?» Hvis det var det, foreslo den et utkast til regel, jeg presiserte det, og en fil ble opprettet.

Etter to måneder med denne arbeidsmåten har jeg mer enn to dusin filer i about-me/feedback/ - regler lært fra bestemte feil. Hver fil er én side i formatet Regel → Hvorfor → Hvordan. Mappen ble et «andre minne» som registrerer mine personlige preferanser og tabuer.

Hver feil gjentas ikke fordi den blir til en regel, og reglene bygger på og forsterker hverandre. Etter seks måneder kjenner Claude prosjektet mitt bedre enn jeg selv husker det etter en måneds pause.

Hvordan legger du juridiske regler, markedsføring og drift inn i CLAUDE.md?#

For de fleste team er CLAUDE.md et rent teknisk dokument: verktøy, byggekommandoer, kodekonvensjoner. Det er nyttig, men utgjør bare en tredjedel av verdien.

Når en gründer vedlikeholder CLAUDE.md, gir det mening å legge til forretningsseksjoner. Tre er viktigst:

Juridiske regler (for regulerte markeder)

Hvis du publiserer tekst i en regulert bransje (finans, medisin, legemiddelreklame, barneprodukter), har forbudte ord juridisk betydning og hører hjemme i CLAUDE.md som uttrykkelige regler. Ikke i noens hode, ikke i et skjermbilde fra en redaktør - i en fil agenten ser i hver økt.

Eksempel for et fintech-prosjekt uten banklisens:

Redaksjonell merknad: Følgende viser formatet på en intern regel for et bestemt prosjekt. Det er ikke en universell tillatelse til å bruke de oppførte begrepene: om en formulering er akseptabel, avhenger av gjeldende lovgivning og selskapets status.

🚨 KRITISK - finansielle formuleringer er forbudt. I materiale rettet mot kunder skal du ikke bruke: «innskudd», «garantert avkastning» eller «investeringsprodukt». Bruk: «sparekonto», «forventet avkastning» og «produkt med variabel rente». Årsaken er de juridiske kravene som gjelder for markedsføring av finansielle tjenester i dette prosjektet.

Denne blokken i CLAUDE.md gjør noe enkelt: Hver gang du ber Claude skrive kundevendt tekst, sjekker agenten den opp mot disse forbudene. Uten regelen dukker forbudte ord opp i hver tredje kampanje. Med den glemmer du at de finnes.

Den samme tilnærmingen fungerer for:

• Medisinske prosjekter (ingen påstander om at noe «behandler» eller «kurerer»).
• Legemiddelreklame (ingen påstander om «mest effektiv»; påkrevde advarsler).
• Enhver regulert bransje med egne regler for reklame.

Markedsføringsstil og tekstformat

Hvis du publiserer tekst regelmessig (sosiale medier, nyhetsbrev, nettsteder), er det verdt å dokumentere formatet i ett avsnitt i CLAUDE.md. Her er et eksempel på hva en influenser eller et byrå som driver en meldingskanal, kan skrive:

Når du skriver innlegg for kanalen, se style/posts.md. Bruk kanalens tillatte formateringsmarkører og unngå «farlige» spesialtegn. Avslutt med en CTA som har en UTM-tag etter denne konvensjonen: utm_source=<channel>&utm_medium=<type>&utm_campaign=<slug>.

Claude pleide å skrive innlegg i «den generelle stilen til et markedsføringsnettsted». Nå følger den formatet ditt, bruker UTM-ene dine og avslører ikke at teksten er AI-skrevet.

Driftsvaner

Utløsende tabeller. Når du sier en bestemt frase, vet agenten hvilke filer den skal åpne og hvilke handlinger den skal utføre. Her er et eksempel for et team som planlegger uke for uke:

«Planlegg uken» → åpne ops/monthly.md, opprett YYYY-WNN.md i samme mappe, og flytt oppgavene fra ops/backlog.md til de aktuelle dagene. «Hva står i oppgavekøen?» → les ops/backlog.md og vis den som en liste. «Avslutt uken» → fyll ut seksjonen «Ukeoppsummering» i filen for inneværende uke.

Med slike tabeller går Claude fra å være en «hjelper som skriver kode» til en «operatør» som kjenner virksomhetens rutiner. Hver mandag sier jeg «la oss planlegge uken», og Claude åpner de riktige filene, leser de månedlige målene og foreslår hvordan oppgavene kan deles opp.

Hvordan sjekker du CLAUDE.md mot en sjekkliste med 12 punkter på 5 minutter?#

1. Størrelse. Er den kortfattet, med omtrent 200 linjer som gjennomgangsmål fremfor en bestått/ikke bestått-grense?
2. Navn. Heter den nøyaktig CLAUDE.md med store bokstaver, ikke claude.md?
3. Plassering. Ligger den i prosjektroten eller i ./.claude/CLAUDE.md?
4. Prosjektbeskrivelse. Gjør de første 5 linjene det tydelig hva prosjektet er, og hvem det er for?
5. Verktøy. Er teknologiene listet uttrykkelig og uten fyll?
6. Struktur. Finnes det et diagram over repositoriet med forklaringer?
7. Ruting. Finnes det en tabell «spørsmål → fil» som viser hvor man finner svar?
8. Prinsipper. Finnes det en seksjon med regler som begynner med «aldri» og «alltid»?
9. Spesifisitet. Kan hver regel etterprøves? («Bruk 2 mellomrom», ikke «skriv vakkert».)
10. Oppdatering. Finnes det en regel om å «sjekke hva som bør legges til på slutten av økten»?
11. Refleksjon. Finnes det en regel om å «registrere oppsummeringen av økten i retrospectives/»?
12. Sikkerhet. Er kritiske forbud (.env, rm -rf) også tatt med i .claude/settings.json?

Hvis du har mer enn fem «nei»-svar, åpner du Claude og gir den denne ledeteksten:

Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix.

Checklist:

Kort nok for oppgaven; gjennomgå rundt 200 linjer uten å behandle dette som et hardt tak

Project description in the first 5 lines

Tools listed explicitly

Repository structure diagram included

“Question → file” table included

Principles section with rules included

Every rule is specific and verifiable

“Update at the end of the session” rule included

“Reflect at the end of the session” rule included

Critical prohibitions included in .claude/settings.json

No duplicates of the same rule in different sections

No dangling links to files that no longer exist

After the audit, give me a list of specific changes that will make the file living.

Hva bør du bruke etter CLAUDE.md: Plan Mode, Skills eller sub-agents?#

CLAUDE.md er grunnlaget. Når den fungerer, kan du legge til tre Claude Code-mekanismer som utfyller hverandre.

Plan Mode. En modus der Claude først lager en plan for endringene, venter på godkjenning fra deg og først deretter begynner å jobbe. Aktiver den med Shift+Tab eller kommandoen /plan. Den løser den viktigste utfordringen med vibe coding: «Jeg ba Claude fikse én ting, og den skrev om halve prosjektet.» Det skjer ikke i Plan Mode - du ser planen før agenten rører noen filer.

Skills. Separate .md-filer i mappen .claude/skills/ med kunnskap om en bestemt type oppgave. En ferdighet for «hvordan skrive en databasemigrering» inneholder for eksempel en bestemt prosedyre, en mal og eksempler. Denne kunnskapen står ikke i CLAUDE.md fordi den er for omfattende. Men når Claude får en oppgave som «skriv en migrering», laster den inn den relevante ferdigheten og følger den.

Sub-agents. Når en oppgave krever mye kontekst (for eksempel gjennomgang av en stor funksjon), kan Claude starte en separat underagent i sin egen rene kontekst. Underagenten gjør arbeidet og returnerer resultatet uten å fylle hovedchatten din med mer kontekst.

Alle tre mekanismene bruker CLAUDE.md som inngangspunkt: De leser den ved starten av arbeidet for å forstå prosjektkonteksten. Derfor fungerer disse funksjonene også dårlig uten en levende CLAUDE.md. Først grunnlaget, så lagene oppå.

Neste steg. Opprett en CLAUDE.md-fil i prosjektroten, kopier malen fra begynnelsen av denne artikkelen, og fyll ut feltene i hakeparenteser med hjelperens ledetekst. Lev deretter med filen: gjør hver agentfeil om til én ny linje. Etter to eller tre uker slutter CLAUDE.md å være «et dokument vi skrev og glemte» og blir noe Claude faktisk konsulterer i hver økt.

Hvis du vil bygge et komplett rammeverk rundt CLAUDE.md - en business/-mappe som en andre hjerne, en about-me/-mappe som en digital projeksjon av deg, grunnleggende ferdigheter og en konfigurert Plan Mode - kan du bruke stegene og eksemplene i denne artikkelen. Ailoot-veiledninger.

Fortsett med Ailoot.