Plan Mode i Claude Code: trinvis vejledning og 4 faser i 2026

Yderligere instruktioner findes i Ailoot-dokumentationen.

Hvad er Plan Mode, og hvorfor er det ikke nok i sig selv?#

I normal tilstand skriver Claude Code kode med det samme, og hvis du ikke holder øje, kan du pludselig få en diff på tværs af mange filer. Plan Mode vender rækkefølgen om: først research og planlægning, derefter godkendelse og så ændringer.

Anthropic beskriver Plan Mode sådan her i den officielle dokumentation:

Det lyder enkelt, men skjuler den vigtigste ændring. Plan Mode ændrer arbejdets rytme: Bliv enige først, handl bagefter. Det er en ændring af tilstand, ikke en kosmetisk justering. Problemet for vibe-kodere er, at AI-agenter har en tendens til at skynde sig. Hvis du beder om at ”tilføje Google-godkendelse” i normal tilstand, skriver Claude koden på et minut, men halvdelen af filerne bliver de forkerte. I Plan Mode bliver den samme anmodning til en tekstplan, som du kan læse på to minutter og rette, før nogen kode bliver rørt.

Her er en fælde, som ingen skriver om i internationale vejledninger. Plan Mode er et svagt værktøj i sig selv: Planen findes kun i den aktuelle samtale. Luk vinduet, og planen er væk. Du kan ikke overdrage den til en anden agent. Der er ingen versioner eller historik. Hvis opgaven er stor (refaktorering af et modul med 30 filer, migrering til en ny database), rammer planen hurtigt kontekstvinduets grænse og begynder at blive dårligere.

Derfor fungerer Plan Mode godt sammen med en plans/-mappe i repository'et. Planen gemmes som plans/2026-05-21-google-oauth.md, opdeles i faser med afkrydsningsfelter, og den næste agent kan tage over. Sådan fungerer konteksteknik – at styre konteksten før prompten, ikke under den.

Hvordan aktiverer du Plan Mode i Claude Code?#

Den hurtigste måde under en session er tastaturet:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Efter to tryk vises indikatoren ⏸ plan mode on nederst i terminalen. Et tredje tryk fører tilbage til normal tilstand. Det er den mest praktiske metode – du skifter på farten, når du kan se, at opgaven vokser.

Den anden metode er at tilføje et præfiks foran en enkelt prompt:

/plan write a plan to migrate the database from MySQL to Postgres

Denne mulighed er nyttig, når du er i auto-accept-tilstand og ikke vil ændre den for hele sessionen. Én anmodning i Plan Mode, og derefter fortsætter arbejdet som før.

Den tredje metode er ved sessionsstart:

claude --permission-mode plan

Brug den, når du på forhånd ved, at en opgave kræver planlægning. For eksempel før en større refaktorering eller migrering.

Den fjerde metode er at angive standardindstillingen i projektets .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Hvornår er det nyttigt? Når et team arbejder på et komplekst system, hvor enhver ændring kan påvirke tilstødende moduler. Så beskytter Plan Mode som standard alle mod utilsigtede ændringer.

Et femte trick, som ofte overses: Ctrl+G åbner planen i en teksteditor. Brug det, når planen næsten er rigtig, men du skal omformulere 2-3 punkter eller tilføje en begrænsning. Rediger den manuelt, gem, og Claude fortsætter med din version.

Hvad er Anthropics kanoniske 4 faser i Plan Mode: Explore, Plan, Implement, Commit?#

Mange vejledninger beskriver 3 faser (Explore-Plan-Execute) eller kun 2 (Plan-Implement). Det er forenklinger. I sin officielle vejledning i bedste praksis beskriver Anthropic præcis 4 faser. Forskellen er vigtig: Når Commit er en separat fase, registrerer du resultatet i stedet for at lade det blive ved ”jeg lavede lige et par flere ændringer her, jeg committer senere” – den mest almindelige årsag til tabt arbejde.

Jo mere præcis planen er, desto færre iterationer kræver implementeringen. Hvis du bruger 10 minutter på planen, tager implementeringen én prompt. Hvis du skitserer planen på et minut, tager implementeringen en time med rettelser.

Sådan ser de 4 faser ud, når Google OAuth tilføjes (et eksempel fra Anthropic Docs):

Prompterne er også forskellige i hver fase. I Explore: ”læs /src/auth, og forstå, hvordan vi håndterer sessioner og login”. I Plan: ”jeg vil tilføje Google OAuth. Hvilke filer skal ændres? Opret en plan”. I Implement: ”implementer OAuth-flowet fra din plan, skriv tests, kør testpakken, og ret fejl”. I Commit: ”lav et commit med en beskrivende besked, og åbn en PR”.

En vigtig nuance: Plan Mode forhindrer ikke Claude i at køre kommandoer til research. Read, LS, Glob, Grep, web fetch og shellkommandoer til udforskning er tilladt. Kun Edit, Write og alle ændrende filsystemhandlinger er forbudt. Det betyder, at Claude kan læse projektstrukturen, køre git log og kigge på tests – men ikke ved et uheld kan ændre noget.

Hvordan læser du Claudes plan og beslutter, om du skal godkende den?#

Når Claude er færdig med at oprette en plan, viser den muligheder for, hvad du kan gøre nu:

• Godkend og start i auto-tilstand
• Godkend og acceptér redigeringer
• Godkend og gennemgå hver redigering manuelt
• Fortsæt planlægningen med feedback
• Forfin med Ultraplan (gennemgang i browseren)

At vide, om en plan bør godkendes, er nøglefærdigheden i Plan Mode. Det er let at trykke automatisk på ”Approve” og derefter måtte tilbageføre commits. Den føjelige AI vil gerne give et hurtigt svar, og du vil hurtigere frem til koden. I tager begge fejl.

En god plan opfylder 7 kriterier:

1. Specifikke filnavne. Ikke ”jeg opdaterer auth”, men ”jeg ændrer src/auth/login.ts:42-58, opretter src/auth/oauth-callback.ts og opdaterer src/auth/session.ts:103.”
2. Rækkefølgen er angivet. Planen er delt op i faser eller trin i stedet for ”jeg gør det hele et eller andet sted”.
3. Eksterne afhængigheder er navngivet. Hvis opgaven kræver et nyt bibliotek, er det angivet. Hvis der er brug for miljøvariabler, er de angivet.
4. Risici er nævnt. En god plan siger: ”Migreringen kan ødelægge eksisterende sessioner; X skal kontrolleres.” En dårlig plan er tavs om bivirkninger.
5. Der er succeskriterier. ”Testene i test/auth består, linteren er ren, og udviklingsserveren starter uden fejl.”
6. Der er ingen antagelser grebet ud af den blå luft. Hvis Claude siger ”jeg bruger bibliotek Z”, så kontrollér: Har du overhovedet installeret det i projektet? Hvis AI'en har fundet på det, vil du kunne se, at det ikke er nævnt i package.json.
7. Planen kan være på skærmen. Hvis planen fylder 200 linjer for en enkel funktion, er opgaven sandsynligvis for stor til én plan. Del den op.

Når en plan ikke består kontrollen, er der tre muligheder:

• Fortsæt planlægningen med feedback – giv Claude en konkret kommentar om, hvad du ikke bryder dig om, så skriver den planen om.
• Ctrl+G – åbn planen i en editor, rediger den manuelt, og gem. Claude fortsætter med din version.
• Forfin med Ultraplan – planen sendes til browsertilstanden i Claude Code på web, hvor du gennemgår afsnit og kommenterer, og derefter kører den lokalt eller i skyen.

Hvis noget går galt midt i implementeringen, skal du ikke forcere det. Gå tilbage til Plan Mode, og skriv planen om. Det er 10 gange billigere end at tilbageføre 40 commits senere.

Plan Mode + en plans/-mappe: en kombination til lange kontekster#

Plan Mode er en tilstand i Claude Code. Mappen plans/ er en metode, der bygger oven på den. Hvis du bruger Plan Mode uden en mappe, rammer du grænsen efter en times arbejde.

Sådan hænger det sammen. Claudes kontekstvindue er sessionens hukommelse. Der kan være 1 million tokens i Opus 4.7, men det er hele samtalens omfang. Hvis du planlægger en kompleks opgave i én samtale, derefter beder om implementering, så diskuterer en fejl og derefter noget andet, bliver vinduet ”oppustet”. Claude begynder at glemme tidlige beslutninger, forveksle kontekster og stille spørgsmål igen.

Løsningen er den gyldne regel: én opgave – én samtale.

Sådan gør du:

1. Samtale 1 – udform planen. Aktivér Plan Mode, beskriv opgaven, og Claude opretter en plan. Gem planen i plans/2026-05-21-feature-name.md. Luk vinduet.
2. Samtale 2 – del planen op i faser. Åbn en ny chat. Bed om: ”tag plans/2026-05-21-feature-name.md, og del den op i faser”. Gem den opdaterede fil.
3. Samtale 3 – implementer fase 1. Åbn en ny chat. Bed om: ”implementer fase 1 fra plans/2026-05-21-feature-name.md, og sæt hak ved punkterne, efterhånden som du gennemfører dem”. Luk vinduet.
4. Samtale 4 – implementer fase 2. Gør det samme.

Hvad giver det dig? Kontekstvinduet i hver samtale forbliver friskt. Claude i fase 3 kender ikke detaljerne fra fase 1, men kender planen, fordi plans/-filen ligger i repository'et. Den næste agent (uanset om det er en subagent, en ny session eller en kørsel via /goal) kan tage planen op og fortsætte.

Sammenligning af tilgange:

Hver funktion har sin egen planfil. Når du tre måneder senere har brug for at huske, hvorfor du valgte én betalingsudbyder frem for et alternativ, kan du åbne den relevante plan og læse beslutningshistorikken: hvad der blev diskuteret, hvilke muligheder der blev overvejet, og hvorfor netop denne vej blev valgt.

Det er levende arbejdsplaner; statisk dokumentation bliver forældet i løbet af nogle måneder.

Hvordan kan du få Claude til at arbejde, mens du sover, med Plan Mode og /goal?#

Den største begrænsning ved lange AI-sessioner er ikke selve modellen, men personen, der trykker på Enter. Hver gang Claude når slutningen af en runde, venter den på dit svar. /goal fjerner den ventetid.

Syntaksen er enkel:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

Betingelsen må være op til 4000 tegn. Ét mål pr. session. Efter hver runde gennemgår Haiku-mini-modellen transskriptionen og beslutter: ”betingelse opfyldt – afslut” eller ”ikke opfyldt – næste runde”. Evaluatoren kalder ikke værktøjer; den læser kun.

Aliaser til at rydde den: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Kombinationen med Plan Mode ser sådan ud:

1. Aktivér Plan Mode (tryk på Shift+Tab to gange).
2. Bed om: ”opret en plan for at migrere databasen fra MySQL til Postgres, gem den i plans/2026-05-21-postgres-migration.md med faser og kriterier”.
3. Gennemgå planen, rediger den, og godkend den.
4. Afslut Plan Mode (tryk på Shift+Tab én gang til).
5. Sæt et mål: ”gennemfør alle faser i plans/2026-05-21-postgres-migration.md, sæt hak ved felterne, alle tests består, eller stop efter 50 runder”.
6. Luk din bærbare computer, og gå i seng.

Om morgenen skal du kontrollere resultatet: enten ”✓ mål fuldført” eller ”◎ stoppede efter 50 runder”, sammen med en historik over det udførte arbejde.

Der er tre vigtige regler for /goal, ellers spilder du tokens:

Regel 1: En målbar sluttilstand. ”Få det til at se pænt ud” er dårligt. ”npm test returnerer 0, npm run lint returnerer 0, og en post er føjet til CHANGELOG.md” er godt.

Regel 2: Udtrykkelig verifikation. Betingelsen bør henvise til noget, der kan verificeres: en kommando, en fil eller et endpoint. Ikke ”alt virker”, men ”curl localhost:3000/api/users returnerer 200”.

Regel 3: Begræns antallet af runder. Tilføj altid ”eller stop efter N runder”. Anthropic anbefaler udtrykkeligt dette i dokumentationen:

Hvis du aktiverer /goal uden ”eller stop efter”, kan budgettet være væk om morgenen.

Hvilken 4-trinscyklus gør Plan Mode til en ingeniørproces?#

En almindelig fejl er at spørge ”hvordan løser jeg det?”: Claude giver en løsning, du anvender den, men intet virker, eller tingene bliver værre. Det er den ”føjelige AI”: Den er trænet til at svare hurtigt, og du vil hurtigere frem til koden. En 4-trinscyklus løser det.

4-trinscyklussen stopper denne adfærd. Den bruges sekventielt i én Plan Mode-session:

Trin 1. Fastslå fakta uden en løsning.

Prompt: ”Jeg oplever følgende: [symptombeskrivelse]. Din opgave nu er at fastslå fakta. Alle løsninger, idéer og råd er forbudt. Kun: hvad jeg observerer, hvilke trin der kan gentages, hvilke data der er tilgængelige, og hvilke data der mangler. Ubetinget stopbetingelse: Foreslå IKKE løsninger; dokumentér kun diagnosen.”

Det stopper AI'ens første impuls: ”her er løsningen”. Claude skal standse ved ”hvad der er kendt, og hvad der er ukendt”.

Trin 2. Udvikl muligheder med forbilleder.

Prompt: ”Nu hvor diagnosen er fastslået, skal du finde eksempler online på løsninger på lignende problemer. Mindst 3 forskellige tilgange. For hver: et link til den primære kilde, en kort beskrivelse samt fordele og ulemper for vores situation.”

Det stopper AI'ens anden impuls: ”find på en løsning ud af det blå”. Vi får den til at gå ud i verden og hente tilgange tilbage, som kan kontrolleres.

Trin 3. Detaljeret plan med risici.

Prompt: ”Tag den bedste mulighed fra trin 2, og lav en detaljeret plan: hvilke konkrete filer der skal berøres, hvad der skal tilføjes, hvad der skal fjernes, hvilke tests der skal skrives, hvad der kan gå i stykker, og hvilke risici der ligger 2-3 trin fremme.”

Det er den velkendte Plan-fase, men med én forskel: Den bygger på de verificerede muligheder fra trin 2, ikke på Claudes gæt.

Trin 4. Kontrollér planen selv.

Prompt: ”Lav nu en obligatorisk selvkontrol. Gennemgå ærligt planen igen: Er der steder, hvor du har grebet noget ud af den blå luft uden at verificere det mod kode, dokumentation eller et eksempel fra trin 2? Markér dem i så fald, og revidér planen.”

Det er det sidste filter. Claude skal kontrollere sin egen ræsonnering og indrømme, hvor den hallucinerede. Mindst 2 punkter i planen bliver som regel revideret i dette trin.

Efter de 4 trin er planen klar til godkendelse. Du går videre til implementeringen med vished om, at opgaven er forstået, mulighederne er blevet vejet, og risiciene er overvejet.

Metoden er beregnet til at diagnosticere svære fejl og træffe arkitekturbeslutninger, hvor omkostningen ved en fejl er høj. Anvendt på Plan Mode fjerner den det største problem for vibe-kodere: ”AI'en gav mig en løsning, jeg anvendte den, og alt gik i stykker.”

Hvilke 5 færdige prompts fungerer i Plan Mode til almindelige opgaver?#

Skabelon 1. Refaktorering af et modul.

I'm enabling Plan Mode. Task: refactor the {module-name} module.

Step 1: Study the current structure of the {module-path} module. Describe:
- which files are part of the module
- which external dependencies it has
- which parts are duplicated
- which functions are overcomplicated

Step 2: Find 2-3 examples online of refactoring similar modules.
At least 1 source must be official Anthropic or related framework documentation.

Step 3: Create a refactoring plan in plans/YYYY-MM-DD-refactor-{module}.md:
- which files to rename
- which functions to extract into separate modules
- which tests to keep and which to rewrite
- risks: what could break for users

Step 4: Self-check. Are there any assumptions in the plan that are "pulled out of thin air"?
Rewrite or remove them.

Skabelon 2. Databasemigrering.

I'm enabling Plan Mode. Task: migrate the database from {old} to {new}.

Step 1: Study the current database schema using {schema-reading-command}. Describe:
- which tables exist and their size
- which relationships, indexes, and constraints there are
- where migrations are stored
- which data is critical

Step 2: Find precedents for {old → new} migrations in production projects.
At least 3 different approaches: pg_dump, dual-write, blue-green.
For each, list the pros and risks for our data size.

Step 3: Create a migration plan in plans/YYYY-MM-DD-db-migration.md:
- phases (backup, migration, verification, switchover)
- success criteria for each phase
- rollback plan if something goes wrong
- downtime or no downtime

Step 4: Self-check. Are all figures supported by documentation?
Have all steps been mentally checked against the dev environment?

Skabelon 3. Tilføjelse af en ny funktion.

I'm enabling Plan Mode. Task: add the {description} feature to the project.

Step 1: Study how similar features currently work in the project.
Specifically, look at:
- {file-1}
- {file-2}
- which architectural patterns are used
- which tests are written for similar features

Step 2: Find how this feature is implemented in open-source projects
with a similar architecture. At least 2 different approaches.

Step 3: Create a plan in plans/YYYY-MM-DD-feature-{name}.md:
- list of new files
- list of changed files with specific lines
- implementation sequence
- which tests to add
- what to add to CLAUDE.md as a rule for future sessions

Step 4: Self-check. Does the plan follow the project's architecture?
Does it assume libraries that haven't been installed yet?

Skabelon 4. Skrivning af tests.

I'm enabling Plan Mode. Task: cover the {name} module with tests.

Step 1: Study the {path} module. Identify:
- public functions and their signatures
- internal functions we will NOT test (implementation details)
- edge cases: empty input, errors, concurrent access

Step 2: Find test examples for a similar class of tasks
in popular open-source projects using the same framework.

Step 3: Create a test plan in plans/YYYY-MM-DD-tests-{module}.md:
- for each public function, a list of tests
- which mocks are needed
- which fixtures
- which verification approach (assertion style)

Step 4: Self-check. Do all tests check behavior rather than implementation?
Does the coverage include edge cases?

Skabelon 5. Fejlsøgning på en kompleks fejl.

I'm enabling Plan Mode. Task: understand the cause of the error {symptom-description}.

Step 1: ESTABLISH THE FACTS. Solutions and ideas are prohibited. Only:
- what I observe (exact wording of the error)
- reproducible steps
- what data is available (logs, traces, library versions)
- what data is missing (what needs to be collected additionally)

Step 2: Find precedents for this error.
At least 3 sources: GitHub issues, documentation.
For each, provide a link and a brief summary of the solution.

Step 3: Create a diagnostic plan in plans/YYYY-MM-DD-bug-{name}.md:
- which hypotheses to check (sorted by likelihood)
- which commands/scripts to run to check each one
- the expected result of each check

Step 4: Self-check. Are there any hypotheses in the plan that are "pulled out of thin air"?
Are all hypotheses tied to facts from Step 1?

Kopiér hver skabelon, erstat {parameters} med dine egne, og indsæt den i Claude Code i Plan Mode. Resultatet er en brugbar plan i plans/, som du godkender og bruger til implementeringen.

Plan Mode eller normal tilstand: hvilken skal du vælge?#

Anthropic siger det direkte i sin dokumentation:

Den citerede vejledning fra Anthropic skelner mellem små ændringer med klart omfang og arbejde med usikker tilgang, ukendt kode eller afhængigheder på tværs af filer. Vurder den faktiske diff, bivirkninger og kontroller; en kort målbeskrivelse alene er ikke en sikkerhedsgrænse.

Spring kun en separat plan over, når den faktiske diff er lille, forstået og har lav risiko. Planlæg, når du skal finde tilgangen eller koordinere risikable ændringer på tværs af komponenter. Kendskab til filnavnene eller evnen til at opsummere målet i én sætning fjerner ikke risici ved migrering, godkendelse eller dataintegritet.

Beslutningstabel:

Spørg før valg af tilstand, om tilgang, bivirkninger og verifikation er forstået. Arbejd direkte på en lille, lokal ændring med lav risiko og en tydelig kontrol. Planlæg først ved usikkerhed, ukendt kode, migrering, godkendelse eller koordinering mellem komponenter, selv hvis du allerede kan navngive alle 3-5 berørte filer.

Hvordan kombinerer du Plan Mode + CLAUDE.md + subagenter for pålideligt arbejde?#

CLAUDE.md er en fil, som Claude læser ved starten af hver session, også i Plan Mode. Hvis CLAUDE.md siger ”hardkod aldrig datoer; hent dem altid fra databasen”, vil planen aldrig foreslå hardkodning. Hvis en sådan regel mangler, kan planen foreslå hvad som helst.

Kombinationen fungerer sådan:

Lag 1. CLAUDE.md fastlægger reglerne.

Filen angiver projektets stack, arkitekturprincipper, forbud (”brug ikke forældede API'er”) og krav (”alle e-mails skal gå gennem et delt layout”). Detaljeret vejledning: Sådan konfigurerer du CLAUDE.md.

Lag 2. Plan Mode anvender reglerne på opgaven.

Når du aktiverer Plan Mode og beder om at ”tilføje OAuth”, læser Claude CLAUDE.md, ser reglerne (”gem tokens i Redis, ikke i databasen”) og tager straks højde for dem i planen. Planen følger projektets arkitektur.

Lag 3. Subagenter fordeler arbejdet.

Hvis planen er delt op i faser, kan hver fase tildeles en separat subagent. Hver subagent arbejder i sit eget kontekstvindue uden at fylde det primære. Planen i plans/ forbliver den centrale sandhedskilde: Subagenter læser den, gennemfører deres fase og opdaterer afkrydsningsfelterne.

Hvilke 7 fejl ødelægger Plan Mode?#

Fejl 1. Planen findes kun i chatten.

Symptom: Du skrev en plan, lukkede vinduet og skal vende tilbage næste dag – men der er intet; konteksten er væk. Løsning: Gem altid planen i plans/YYYY-MM-DD-feature-name.md i repository'et. Chatten er et skrivebord; filen er et arkiv.

Fejl 2. Alle opgaver er i én chat.

Symptom: I én session diskuterer du auth, derefter en migrering, så UI-design og til sidst en fejl. Kontekstvinduet bliver ”oppustet”, og Claude glemmer tidligere ting. Løsning: én opgave – én samtale. Færdig med planen? Luk vinduet. Skal du begynde implementeringen? Åbn et nyt.

Fejl 3. Én plan på 3000 linjer uden faser.

Symptom: Der er en plan, men den har ingen afkrydsningsfelter eller opdeling. Det er umuligt at se, hvad der er gjort, og hvad der mangler. Delegering er umulig. Løsning: Del hver plan op i 3-7 faser. Hver fase er en liste med afkrydsningsfelter og konkrete handlinger.

Fejl 4. Ingen grundig research før planen.

Symptom: Claude foreslår en løsning ud af det blå, fordi du ikke bad den lede efter forbilleder. En uge senere finder du ud af, at der længe har eksisteret en bedre tilgang i open source. Løsning: Trin 2 i 4-trinscyklussen – få Claude til at finde 2-3 eksempler online, før den opretter en plan.

Fejl 5. Den føjelige AI giver en løsning uden en diagnose.

Symptom: Du spørger ”hvordan løser jeg fejl X?”, Claude giver en løsning, du anvender den, og intet virker, eller tingene bliver værre. Løsning: Begynd altid med ”fastslå fakta; løsninger er forbudt”. Først efter diagnosen går du videre til mulighederne.

Fejl 6. Selvkontrollen springes over.

Symptom: Planen ser sandsynlig ud, men indeholder 2-3 antagelser, der er ”grebet ud af den blå luft” (et opdigtet bibliotek, et API, der ikke findes, eller en forkert version). Implementeringen går i stykker på disse punkter. Løsning: Trin 4 i 4-trinscyklussen – få Claude til ærligt at gennemgå sin plan igen og markere antagelser.

Fejl 7. Vage betingelser i /goal.

Symptom: Du sætter /goal make it look nice, lader den køre natten over og vågner til en opbrugt kvote på $200. Løsning: Brug kun målbare betingelser med en verifikationskommando og et obligatorisk ”eller stop efter N runder”. Ingen ”gør det godt” eller ”puds det af”.

Den ottende fejl, som vibe-kodere oftest begår, er at ignorere selve idéen med en plans/-mappe. Plan Mode uden en plans/-mappe er ikke en metode; det er et legetøj. Hvis du bruger Plan Mode, men ikke opretter filer, får du 10% af dens muligheder.

Hvad bør du gøre efter din første oplevelse med Plan Mode?#

Tre konkrete trin i stigende sværhedsgrad:

Trin 1. Konfigurér CLAUDE.md, hvis du ikke allerede har en.

Uden CLAUDE.md fungerer Plan Mode ”i et vakuum” – Claude kender ikke projektets regler og foreslår planer, der bryder arkitekturen. Fuld vejledning: Sådan konfigurerer du CLAUDE.md. En minimal CLAUDE.md er på 50-80 linjer, der beskriver stacken, reglerne og forbuddene. Længden er sekundær. Det er specificiteten, der betyder noget.

Trin 2. Opret en plans/-mappe i repository'et.

Tilføj en plans/-mappe i projektets rod. Aftal et navngivningsformat: YYYY-MM-DD-feature-name.md. Hver plan får sin egen fil. Efter en måned har du 20-30 filer; efter seks måneder 100+. Det er en levende historik over projektets beslutninger.

Trin 3. Prøv /goal på én opgave.

Vælg en opgave, du normalt udfører manuelt på 30-40 minutter. Aktivér Plan Mode, opret en plan, og gem den i plans/. Afslut Plan Mode. Sæt /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Luk din bærbare computer i en time, og lav noget andet. Kom tilbage, og kontrollér resultatet.

De tre trin er minimum. Det bygges gradvist op; prøv ikke at samle det hele på én aften. Begynd med CLAUDE.md, tilføj plans/ efter en uge, og prøv /goal natten over efter en måned.

Når du er klar, kan du møde Ailoot.