Så konfigurerar du Claude Code för Opus 5 och Fable 5

Den bästa CLAUDE.md-filen är inte den som beskriver hela din utvecklingsprocess. Den är den minsta fil som hindrar Claude från att upprepa samma viktiga misstag.

Den skillnaden blir ännu viktigare med Opus 5 och Fable 5. Anthropic uppger att de tog bort mer än 80 procent av Claude Codes systemprompt för avancerade modeller utan någon mätbar försämring i sina utvärderingar av kodningsförmåga. Lärdomen är alltså inte att Claude ska lämnas helt utan instruktioner. Håll i stället den beständiga kontexten liten, ange de verkliga begränsningarna tydligt och läs bara in specialiserade procedurer när de behövs.

En bra konfiguration av Claude Code skiljer mellan fem typer av information:

• Instruktioner som alltid behövs hör hemma i CLAUDE.md.
• Sökvägsspecifika begränsningar hör hemma i .claude/rules/ eller en underordnad CLAUDE.md.
• Återanvändbara procedurer hör hemma i skills.
• Deterministiska kontroller hör hemma i hooks, behörigheter och inställningar.
• Föränderlig projektstatus hör hemma i en roadmap, ett ärende eller en implementeringsplan.

När lagren väl har separerats får Claude mindre brus, och de instruktioner som återstår får större tyngd.

Källa: Anthropic — The new rules of context engineering for Claude 5 generation models

Så läser Claude Code in instruktioner

Claude Code kan läsa CLAUDE.md på flera nivåer:

• Hanterad policy: organisationsövergripande instruktioner som installeras av IT.
• Användare: ~/.claude/CLAUDE.md, som används i alla dina projekt.
• Projekt: ./CLAUDE.md eller ./.claude/CLAUDE.md, som normalt checkas in i Git.
• Lokalt projekt: ./CLAUDE.local.md, för personliga projektspecifika preferenser och normalt ignorerad av Git.
• Underordnad: en CLAUDE.md i en underkatalog, som läses in när Claude läser filer i den katalogen.

Filer ovanför arbetskatalogen läses in i sin helhet vid start. Filer under den läses in vid behov när Claude öppnar filer i dessa kataloger.

Instruktionerna från de olika lagren läggs samman. En projektinstruktion visas senare i kontexten än en användarinstruktion, men det här är inte ett tillförlitligt arvssystem där alla konflikter löses entydigt. Anthropic varnar för att Claude kan välja godtyckligt när instruktioner motsäger varandra. Ta bort konflikten i stället för att försöka vinna genom upprepning.

Använd /context för att se vilka instruktionsfiler som har lästs in. /init kan skapa en första projektfil. Granska den och behåll bara beständiga fakta som inte är uppenbara.

Anthropic rekommenderar färre än 200 rader per CLAUDE.md. Se det som ett tak, inte ett mål. En kompakt driftmanual på 150 rader kan fortfarande vara för omfattande.

Källa: Claude Code docs — How Claude remembers your project

Vad som hör hemma i din globala CLAUDE.md

Din användarfil läses in i alla projekt, så varje rad bör verkligen vara relevant över projektgränserna. Bra kandidater är:

• önskad svarslängd och hur ofta lägesuppdateringar ska ges;
• hur självständigt Claude ska fatta rutinmässiga och reversibla beslut;
• när Claude ska fråga i stället för att agera;
• dina normala gränser för omfattning och bieffekter;
• stabila regler för säkerhet eller behörighet;
• personlig terminologi eller egna förkortningar som används i flera projekt;
• en kort delegeringsregel om den modell du brukar använda delegerar för lättvindigt.

Lägg inte projektkommandon, ramverkskonventioner, kodbasens arkitektur, aktuella milstolpar, listor över plugins, tillfälliga regler för modellrouting eller en komplett granskningsprocess här. Dessa detaljer gäller inte överallt, men skulle förbruka kontext överallt.

En praktisk användarfil kan vara så här liten:

# Communication
- Lead with the outcome.
- Keep progress updates to important findings or changes of direction.
- Match document length to the task. Do not add filler sections or duplicate summaries.

# Autonomy and scope
- Make routine, reversible decisions independently.
- Briefly flag a material flaw or false premise, then continue with the requested task.
- Complete the task at its intended scope. Stop before unrequested external or irreversible actions.

# Authorization
- Treat commit, push, merge, deploy, publication, destructive cleanup, and credential use as separate actions unless I explicitly bundle them.

# Delegation
- Delegate only substantial, genuinely independent work. Do not create subagents for small tasks or merely to double-check your own work.

Det här är ett exempel, inte en universell mall. Behåll bara regler som beskriver hur du arbetar och som är användbara i nästan alla projekt.

Vad som hör hemma i projektets CLAUDE.md

Projektfilen ska snabbt orientera Claude och lyfta fram de få fakta som inte kan härledas på ett säkert sätt från kodbasen.

Ta med:

1. Syfte

En eller två meningar som förklarar vad kodbasen är och vad den inte är.

2. Sanningskällor

Peka ut de auktoritativa filerna för arkitektur, API-kontrakt, produktomfattning, genererad kod eller aktuella planer. Använd en vanlig sökväg när Claude bara ska läsa ett stort dokument om det är relevant.

3. Exakta kommandon

Ange de kanoniska kommandona och vilken arbetskatalog de ska köras från:

• fokuserat testkommando;
• fullständigt testkommando, om det skiljer sig;
• typkontroll;
• lint- eller formateringskontroll;
• bygge;
• ett säkert smoke test genom den verkliga körvägen, om projektet har ett sådant.

Konkreta acceptanskommandon är användbara. Att upprepa ”verifiera ditt arbete”, ”dubbelkolla allt” och ”starta en verifieringsagent” är det inte.

4. En kort arkitekturöversikt

Namnge de viktigaste gränserna och var ansvaret ligger. Återge inte hela filträdet i löptext.

5. Icke uppenbara invarianter och fallgropar

Det här är ofta avsnittet med högst värde. Exempel:

• genererade filer får inte redigeras direkt;
• en migrering får bara utökas;
• en tjänst kräver en viss arbetskatalog;
• ett paket äger ett gemensamt schema;
• testerna går igenom lokalt men kräver ytterligare en kontroll i körmiljön;
• en till synes oanvänd fil läses in dynamiskt.

6. Kriterier för när arbetet är klart

Ange de konkreta bevis som är viktiga för kodbasen: namngivna kommandon, genererade artefakter, obligatoriska granskningssteg eller ett godkänt smoke test. Håll det specifikt och kort.

En kompakt projektfil kan se ut så här:

# Repository purpose
This service accepts billing events and writes normalized ledger entries. The public API contract lives in `docs/api-contract.md`.

# Commands
Run from the repository root:
- Focused tests: `pnpm test --filter billing`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`
- Production build: `pnpm build`

# Architecture
- `src/http/` owns request parsing and authentication.
- `src/ledger/` owns business rules and database writes.
- `packages/schema/` is the source of truth for shared event types.

# Invariants
- Do not edit files under `src/generated/`; run `pnpm generate`.
- Database migrations are append-only after merge.
- All ledger writes must remain idempotent by event ID.

# Current work and detailed procedures
- Current scope: `docs/ROADMAP.md`
- Release procedure: use the `release` skill.
- API-specific rules: `.claude/rules/api.md`

Det sista avsnittet är viktigt: det hänvisar till detaljer utan att kopiera in dem i kontext som alltid läses in.

Underordnad CLAUDE.md eller sökvägsspecifika regler?

Använd en underordnad CLAUDE.md när en sammanhållen del av trädet har egna lokala konventioner. Ett frontendpaket, en infrastrukturkatalog eller en mobilapp i ett monorepo kan till exempel ha nytta av en egen fil.

Använd .claude/rules/*.md när en begränsning följer filmönster eller berör flera kataloger. En regel kan använda paths i sin frontmatter:

---
paths:
  - "src/api/**/*.ts"
  - "tests/api/**/*.test.ts"
---

# API rules
- Validate external input with the shared schema package.
- Return errors through the standard API error envelope.
- Keep handlers free of direct database access.

Regler utan paths läses in villkorslöst. Sökvägsspecifika regler läses in när Claude öppnar matchande filer, vilket håller orelaterade instruktioner borta från sessionen.

En användbar uppdelning är:

• Underordnad CLAUDE.md: konventioner som tillhör en katalog eller ett delsystem.
• Sökvägsspecifik regel: en begränsning knuten till filtyper eller mönster i kodbasen.

Källa: Claude Code docs — CLAUDE.md and .claude/rules/

Använd skills för procedurer

En skill är rätt plats för ett återanvändbart arbetsflöde, exempelvis att:

• granska en pull request;
• utreda en produktionsincident;
• publicera en release;
• genomföra en databasmigrering;
• utföra en säkerhetsgranskning;
• generera en viss artefakt.

Projektets teamdelade skills finns i kodbasen under <repo>/.claude/skills/<skill-name>/SKILL.md. Checka in dem i Git så att alla som arbetar i projektet får samma arbetsflöde. Personliga skills som används i flera projekt finns under ~/.claude/skills/<skill-name>/SKILL.md.

Varje skill är en katalog med en obligatorisk SKILL.md. Lägg en specifik description i YAML-frontmatter och därefter instruktionerna i Markdown. Skript, mallar, exempel och referensfiler är valfria. Claude Code listar normalt namnet och beskrivningen för en skill så att den går att hitta, inom ramen för sin listningsbudget, och läser sedan in de fullständiga instruktionerna när denna skill används. I ett monorepo kan ett paket äga skills under <package>/.claude/skills/; de blir tillgängliga när Claude har läst eller redigerat en fil i den delen av trädet.

Det här är progressiv inläsning i praktiken. Lägg en kort trigger eller hänvisning i CLAUDE.md och placera sedan proceduren, skripten, referenserna, mallarna, verifieringsstegen och fallgroparna i en skill.

Kopiera inte samma checklista för release till projektets CLAUDE.md, en skill och en roadmap. Dubblering leder till att innehållet glider isär och instruktionerna börjar motsäga varandra.

Källa: Claude Code docs — Extend Claude with skills

Använd hooks och inställningar för att upprätthålla regler

CLAUDE.md är kontext, inte en mekanism för att tvinga fram beteenden. Claude läser filen och försöker följa den, men Anthropic säger uttryckligen att efterlevnad inte kan garanteras.

Använd hooks, behörigheter eller inställningar när beteendet måste vara deterministiskt. Bra användningsområden är att:

• blockera ett farligt shell-kommando innan det körs;
• köra en formatterare efter redigeringar;
• logga verktygsaktivitet;
• skicka en avisering när en lång uppgift är klar;
• tillåta eller neka specifika verktyg eller kommandomönster;
• köra ett fast valideringsskript vid en viss livscykelhändelse.

Hooks kan köra shell-kommandon, HTTP-anrop, prompts eller subagenter vid definierade livscykelhändelser. För en enkel deterministisk säkerhetsåtgärd är en kommandohook eller behörighetsregel bättre än ett stycke som ber Claude att komma ihåg åtgärden.

Utdata från hooks kan fortfarande skickas tillbaka till Claude, så hooks är inte automatiskt kostnadsfria i fråga om kontext. Hooks utlöses tillförlitligt när deras konfigurerade händelse och matchare gäller. En kommando- eller HTTP-hanterare kan tvinga fram ett fast beteende; en prompt- eller agenthook använder fortfarande en modell och kan variera. Det skiljer sig från att hoppas att Claude minns en regel i löptext vid rätt tillfälle.

Källor: Claude Code hooks reference och Claude Code settings

Håll roadmaps och planer utanför CLAUDE.md

En roadmap svarar på frågan ”vad gör vi nu?” CLAUDE.md svarar på ”vad behöver Claude veta varje gång?” Det är två skilda frågor.

Lägg föränderlig information på en beständig plats utanför CLAUDE.md, exempelvis:

• docs/ROADMAP.md för milstolpar och aktuell omfattning;
• ett ärendehanteringssystem för ansvar och status;
• en implementeringsplan för en omfattande förändring i flera faser;
• ett överlämnings- eller kontrollpunktsavsnitt i planen när arbetet måste fortsätta i en ny kontext.

Projektets CLAUDE.md ska hänvisa till den auktoritativa källan, inte kopiera dess innehåll. På så sätt undviker du att inaktuella milstolpar, gamla uppgiftslistor, föråldrade commit-hashar och gårdagens beslut framstår som permanenta instruktioner.

Samma regel gäller efter kontextkomprimering eller i en ny session: hänvisa Claude till den aktuella planen och den exakta nästa fasen i stället för att klistra in hela historiken i prompten igen.

@-importer organiserar kontext men skjuter inte upp inläsningen

CLAUDE.md stöder importer som:

See @README.md and @docs/git-instructions.md.

Importer kan göra en fil enklare att underhålla, men det importerade innehållet expanderas och läses in tillsammans med den CLAUDE.md-fil som hänvisar till det. En import skapar inte en ny gräns för behovsstyrd inläsning: när instruktionsfilen läses in följer dess importer med.

Om ett stort dokument bara är användbart ibland kan du skriva sökvägen inom backticks och tala om för Claude när det ska läsas. Använd en skill eller sökvägsspecifik regel när du behöver verkligt villkorad inläsning.

Källa: Claude Code docs — Import additional files

Låt auto memory lagra upptäckter, inte policy

Claude Code har också auto memory: anteckningar som Claude skriver utifrån rättelser, felsökningsfynd och arbetssätt som har bekräftats fungera. Det är separat från CLAUDE.md och lagras för varje kodbas.

Använd auto memory för lärdomar som Claude gör under arbetet. Använd CLAUDE.md för regler som du avsiktligt vill äga och granska. Förlita dig inte på auto memory för säkerhetspolicy, behörighetsgränser eller teamstandarder.

Anthropic dokumenterar för närvarande att de första 200 raderna eller 25 kB av auto memory läses in i varje session. Det är ytterligare ett skäl att hålla innehållet kurerat i stället för att behandla det som en aktivitetslogg.

Källa: Claude Code docs — Auto memory

Beskriv resultatet i prompten, inte varje enskilt steg

För dagens Claude-modeller definierar en bra uppgiftsprompt normalt:

• Resultat: vad som måste finnas eller vara sant.
• Varför: avsikten som påverkar avvägningarna.
• Utgångsläge: relevanta symtom, loggar eller känd status.
• Referenser: den kod, specifikation, design eller plan som är auktoritativ.
• Omfattning: vad som får ändras och vad som inte får ändras.
• Fattade beslut: val som Claude inte ska ompröva utan motstridiga bevis.
• Acceptans: kommandon, artefakter, beteenden eller granskningsbevis som visar att arbetet är klart.
• Bieffekter: om commit, push, deploy, publicering eller destruktiv rensning är godkänd.
• Svar: önskad detaljnivå i slutsvaret.

Det här är en fullständig specifikation. Det betyder inte att varje prompt behöver ett formulär, och inte heller att ordnade steg alltid är dåliga.

Använd stegvisa instruktioner när ordningsföljden är avgörande: migreringar, incidenthantering, reglerade arbetsflöden, riskfyllda tillståndsändringar eller en process som måste ge fullständig täckning. Vid vanlig implementering bör du ange gränssnitten och kontrollpunkterna och sedan låta Claude inspektera koden och välja väg.

Anthropics allmänna rekommendationer för prompting förespråkar fortfarande numrerade steg när ordningsföljd eller fullständighet är viktig. Förbättringen är inte ”mål i stället för steg”, utan mål och begränsningar som standard; procedurer bara när själva proceduren har ett verkligt värde.

Källa: Anthropic — Prompting best practices

Anpassa för Opus 5

För Claude Code kan Anthropics rekommendationer för Opus 5 omsättas i fyra praktiska förändringar:

• Ta bort generella uppmaningar om omverifiering. Opus 5 verifierar sitt arbete utan att bli tillsagd. Upprepade instruktioner om att dubbelkolla, göra en avslutande verifieringsrunda eller starta en verifierare kan leda till överdriven verifiering och slöseri med tokens.
• Behåll konkreta acceptanskriterier. Exakta kommandon och obligatoriska artefakter definierar vad ”klart” betyder. De skiljer sig från allmänna påminnelser om att kontrollera en gång till.
• Begränsa delegeringen. Opus 5 delegerar lättare än tidigare modeller. Reservera subagenter för omfattande och verkligt självständigt arbete och begränsa antalet parallella grenar när kostnaden spelar roll.
• Begränsa omfattning och synlig längd. Opus 5 kan bredda smala uppgifter och tenderar att skriva längre lägesuppdateringar och dokument. Ange avsedd omfattning, stoppgräns, uppdateringsfrekvens och önskad dokumentlängd.

Instruktionerna kan vara kortfattade. Ersätt inte en gammal verifieringsmanual med en ny manual mot verifiering.

Källa: Anthropic — Prompting Claude Opus 5

Anpassa för Fable 5

Claude Codes modellguide säger att rutinmässiga påminnelser om att testa eller kontrollera oftast är onödiga eftersom Fable 5 redan verifierar sitt arbete oftare än mindre modeller. För långvarigt arbete rekommenderar Anthropics promptguide för Fable 5 däremot mer stöd i prompten och körmiljön:

• gör regelbundna kontroller mot specifikationen uttryckliga;
• använd verifierande subagenter med ny kontext när oberoende verifiering tillför värde;
• förankra lägesbeskrivningar i faktiska verktygsutdata;
• delegera verkligt oberoende spår asynkront;
• låt långlivade subagenter behålla användbar kontext;
• granska ärvda prompts och skills för att hitta alltför styrande instruktioner som skrevs för äldre modeller;
• definiera kontrollpunkter före irreversibla åtgärder, väsentliga ändringar av omfattningen eller indata som bara en människa kan tillhandahålla.

Lägg inte in hela det här mönstret för långvarigt arbete i varje prompt. En liten Fable-uppgift behöver inget styrsystem för autonomt arbete. Använd den extra strukturen när arbetets tidshorisont och risk motiverar den.

Källor: Claude Code docs — Model configuration och Anthropic — Prompting Claude Fable 5

Lägg inte motsägelsefulla modellspecifika standardval i en global CLAUDE.md på användarnivå. Håll stabila preferenser, omfattning och behörighet globala. Placera beteenden som är specifika för Opus eller Fable i rätt skill, arbetsflöde eller körmiljökonfiguration.

En ren konfigurationsstruktur

En mogen kodbas kan använda följande struktur:

~/.claude/
├── CLAUDE.md                    # Personal cross-project preferences
├── rules/                       # Personal rules used across projects
└── skills/                      # Personal reusable workflows

project/
├── CLAUDE.md                    # Small team-shared project orientation
├── CLAUDE.local.md              # Personal project notes; gitignored
├── .claude/
│   ├── settings.json            # Shared permissions, hooks and settings
│   ├── rules/
│   │   ├── api.md               # Path-scoped API constraints
│   │   └── migrations.md        # Path-scoped migration constraints
│   └── skills/
│       ├── release/SKILL.md      # Committed team release workflow
│       └── review-pr/SKILL.md    # Committed team review workflow
├── packages/
│   └── frontend/
│       └── CLAUDE.md            # Frontend-only conventions, loaded on demand
└── docs/
    ├── ROADMAP.md                # Current milestones and status
    └── architecture.md           # Detailed reference, read when needed

CLAUDE.md i roten är indexet och samlingen av beständiga invarianter. Den är inte hela operativsystemet.

Femminutersgranskningen av CLAUDE.md

Granska varje rad och fråga:

1. Gäller det här i nästan varje session på den här nivån?
2. Kan Claude härleda det tillförlitligt från kodbasen?
3. Är det aktuellt, konkret och fritt från motsägelser?
4. Är det en instruktion, en procedur, en regel som ska upprätthållas eller föränderlig status?
5. Skulle ett verkligt misstag återkomma om raden togs bort?

Flytta sedan innehåll konsekvent:

• tillfällig procedur → skill;
• begränsning kopplad till filmönster → .claude/rules/;
• konvention för ett delsystem → underordnad CLAUDE.md;
• deterministisk blockering eller automatisering → hook, behörighet eller inställning;
• milstolpe, status, historik eller aktuell uppgift → roadmap, ärende eller plan;
• stor valfri referens → vanlig sökvägshänvisning som läses in vid behov.

Kör slutligen /context för att bekräfta att rätt filer har lästs in och ta bort motsägelser mellan lagren.

Den praktiska regeln

Konfigurera Claude på samma sätt som du skulle utforma ett bra programvarugränssnitt: en liten stabil kärna, tydliga gränser, tydliga acceptanskriterier och specialiserade funktioner som bara läses in när de behövs.

Med Opus 5 kan du lita på modellens inbyggda självverifiering och i stället styra omfattning, delegering och synlig längd. För långvarigt arbete med Fable 5 bör du lägga till regelbundna kontroller förankrade i faktiska resultat och oberoende verifiering när tidshorisonten motiverar det. I båda fallen ska föränderlig projektstatus hållas borta från permanenta instruktioner.

En kortare CLAUDE.md är inte automatiskt bättre. En mer selektiv fil är det oftast.