Plan Mode i Claude Code: steg-för-steg-guide och 4 faser i 2026

Ytterligare instruktioner finns i Ailoot-dokumentationen.

Vad är Plan Mode, och varför räcker det inte på egen hand?#

I normalläge skriver Claude Code kod direkt, och om du inte håller koll kan du plötsligt få en diff över många filer. Plan Mode vänder på ordningen: först research och planering, sedan godkännande och därefter ändringar.

Anthropic beskriver Plan Mode så här i sin officiella dokumentation:

Det låter enkelt, men döljer den viktigaste förändringen. Plan Mode ändrar arbetsrytmen: kom överens först, agera sedan. Det är en ändring av läget, inte en kosmetisk justering. Problemet för vibe-kodare är att AI-agenter tenderar att rusa i väg. Om du ber Claude att ”lägga till Google-autentisering” i normalläge skriver den koden på en minut, men hälften av filerna blir fel. I Plan Mode blir samma begäran en textplan som du kan läsa på två minuter och korrigera innan någon kod rörs.

Här är en fälla som ingen skriver om i internationella guider. Plan Mode är ett svagt verktyg på egen hand: planen finns bara i den pågående konversationen. Stäng fönstret så går planen förlorad. Du kan inte lämna över den till en annan agent. Det finns inga versioner eller någon historik. Om uppgiften är stor (refaktorering av en modul med 30 filer, migrering till en ny databas) når planen snabbt kontextfönstrets gräns och börjar försämras.

Därför fungerar Plan Mode bra tillsammans med en plans/-mapp i kodförrådet. Planen sparas som plans/2026-05-21-google-oauth.md, delas upp i faser med kryssrutor och kan plockas upp av nästa agent. Så fungerar kontextteknik – att hantera kontext före prompten, inte under den.

Hur aktiverar du Plan Mode i Claude Code?#

Det snabbaste sättet under en session är med tangentbordet:

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

Efter två tryck visas indikatorn ⏸ plan mode on längst ned i terminalen. Ett tredje tryck återgår till normalläge. Det här är det bekvämaste sättet – du växlar direkt när du märker att uppgiften växer.

Det andra sättet är att lägga till ett prefix före en enskild prompt:

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

Det här alternativet är användbart när du är i läget för automatisk acceptans och inte vill ändra det för hela sessionen. En begäran i Plan Mode, sedan fortsätter arbetet som förut.

Det tredje sättet är vid sessionsstart:

claude --permission-mode plan

Använd det här när du vet i förväg att en uppgift behöver planeras. Till exempel inför en större refaktorering eller migrering.

Det fjärde sättet är att ställa in standardläget i .claude/settings.json i projektet:

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

När är det här användbart? När ett team arbetar med ett komplext system där varje ändring kan påverka närliggande moduler. Då skyddar Plan Mode som standard alla mot oavsiktliga ändringar.

Ett femte knep som ofta förbises: Ctrl+G öppnar planen i en textredigerare. Använd det när planen nästan är rätt, men du behöver omformulera 2-3 punkter eller lägga till ett villkor. Redigera den manuellt, spara, så fortsätter Claude med din version.

Vilka är Anthropics kanoniska 4 faser i Plan Mode: Explore, Plan, Implement, Commit?#

Många guider beskriver 3 faser (Explore-Plan-Execute) eller bara 2 (Plan-Implement). Det är förenklingar. I sin officiella guide med rekommenderade arbetssätt beskriver Anthropic exakt 4 faser. Skillnaden spelar roll: när Commit är en separat fas registrerar du resultatet i stället för att lämna det vid ”jag gjorde några ändringar till här, jag committar senare” – den vanligaste orsaken till att arbete går förlorat.

Ju mer precis planen är, desto färre iterationer behövs för implementeringen. Om du lägger 10 minuter på planen tar implementeringen en prompt. Om du skissar planen på en minut tar implementeringen en timme av korrigeringar.

Så här ser de 4 faserna ut när Google OAuth läggs till (ett exempel från Anthropic Docs):

Prompterna skiljer sig också åt mellan faserna. I Explore: ”läs /src/auth och ta reda på hur vi hanterar sessioner och inloggning”. I Plan: ”jag vill lägga till Google OAuth. Vilka filer behöver ändras? Skapa en plan”. I Implement: ”implementera OAuth-flödet från planen, skriv tester, kör testsviten och åtgärda fel”. I Commit: ”skapa en commit med ett beskrivande meddelande och öppna en pull request”.

En viktig nyans: Plan Mode hindrar inte Claude från att köra kommandon för research. Read, LS, Glob, Grep, web fetch och shellkommandon för undersökning är tillåtna. Endast Edit, Write och alla filsystemsåtgärder som ändrar något är förbjudna. Det innebär att Claude kan läsa projektstrukturen, köra git log och titta på tester – men inte råka ändra något.

Hur läser du Claudes plan och avgör om du ska godkänna den?#

När Claude har skapat en plan visar den alternativ för vad du kan göra härnäst:

• Godkänn och starta i automatiskt läge
• Godkänn och tillåt redigeringar
• Godkänn och granska varje redigering manuellt
• Fortsätt planera med återkoppling
• Förfina med Ultraplan (granskning i webbläsaren)

Att veta om en plan ska godkännas är nyckelfärdigheten i Plan Mode. Det är lätt att trycka på ”Approve” automatiskt och sedan behöva återställa commits. Den inställsamma AI:n vill ge ett snabbt svar, och du vill komma snabbare till koden. Ni har båda fel.

En bra plan uppfyller 7 kriterier:

1. Specifika filnamn. Inte ”jag uppdaterar autentiseringen”, utan ”jag ändrar src/auth/login.ts:42-58, skapar src/auth/oauth-callback.ts och uppdaterar src/auth/session.ts:103”.
2. Ordningen är angiven. Planen är indelad i faser eller steg i stället för ”jag gör allt det här någonstans”.
3. Externa beroenden namnges. Om uppgiften kräver ett nytt bibliotek anges det. Om miljövariabler behövs anges de.
4. Risker listas. En bra plan säger: ”Migreringen kan förstöra befintliga sessioner; X behöver kontrolleras.” En dålig plan är tyst om bieffekter.
5. Det finns framgångskriterier. ”Testerna i test/auth passerar, linterverktyget är rent och utvecklingsservern startar utan fel.”
6. Det finns inga antaganden som dragits ur luften. Om Claude säger ”jag använder bibliotek Z”, kontrollera: har du ens installerat det i projektet? Om AI:n hittade på det ser du att det inte nämns i package.json.
7. Planen får plats på skärmen. Om planen tar 200 rader för en enkel funktion är uppgiften förmodligen för stor för en enda plan. Dela upp den.

Om en plan inte klarar kontrollen finns tre alternativ:

• Fortsätt planera med återkoppling – ge Claude en specifik kommentar om vad du inte gillar, så skriver den om planen.
• Ctrl+G – öppna planen i en redigerare, redigera den manuellt och spara. Claude fortsätter med din version.
• Förfina med Ultraplan – planen öppnas i Claude Code på webben i webbläsarläge, där du granskar avsnitt och kommenterar, och sedan kör den lokalt eller i molnet.

Om något går fel mitt under implementeringen, tvinga inte fram en lösning. Gå tillbaka till Plan Mode och skriv om planen. Det är 10 gånger billigare än att återställa 40 commits senare.

Plan Mode + en plans/-mapp: en kombination för lång kontext#

Plan Mode är ett läge i Claude Code. Mappen plans/ är en metod som bygger vidare på det. Om du använder Plan Mode utan en mapp når du gränsen efter en timmes arbete.

Så här fungerar det. Claudes kontextfönster är sessionens minne. Det får plats med 1 miljon tokens i Opus 4.7, men det är hela konversationens volym. Om du planerar en komplex uppgift i en konversation, sedan ber om implementering, därefter diskuterar en bugg och sedan något annat, blir fönstret ”uppblåst”. Claude börjar glömma tidiga beslut, blanda ihop kontexter och ställa frågor igen.

Lösningen är den gyllene regeln: en uppgift – en konversation.

Så här gör du:

1. Konversation 1 – utforma planen. Aktivera Plan Mode, beskriv uppgiften och Claude skapar en plan. Spara planen i plans/2026-05-21-feature-name.md. Stäng fönstret.
2. Konversation 2 – dela upp planen i faser. Öppna en ny chatt. Be: ”ta plans/2026-05-21-feature-name.md och dela upp den i faser”. Spara den uppdaterade filen.
3. Konversation 3 – implementera fas 1. Öppna en ny chatt. Be: ”implementera fas 1 från plans/2026-05-21-feature-name.md och kryssa av punkterna när du är klar med dem”. Stäng fönstret.
4. Konversation 4 – implementera fas 2. Gör samma sak.

Vad ger det här dig? Kontextfönstret för varje konversation förblir opåverkat. Claude i fas 3 känner inte till detaljerna från fas 1, men känner till planen eftersom filen plans/ finns i kodförrådet. Nästa agent (en subagent, en ny session eller en körning via /goal) kan plocka upp planen och fortsätta.

Jämförelse av arbetssätten:

Varje funktion har sin egen planfil. När du tre månader senare behöver komma ihåg varför du valde en betalningsleverantör framför ett alternativ kan du öppna den relevanta planen och läsa beslutshistoriken: vad som diskuterades, vilka alternativ som övervägdes och varför just den här vägen valdes.

Det här är levande arbetsplaner; statisk dokumentation blir inaktuell på några månader.

Hur kan du få Claude att arbeta medan du sover med Plan Mode och /goal?#

Den största begränsningen för långa AI-sessioner är inte själva modellen, utan personen som trycker på Enter. Varje gång Claude når slutet av en tur väntar den på ditt svar. /goal tar bort den väntan.

Syntaxen är enkel:

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

Villkoret får vara upp till 4000 tecken långt. Ett mål per session. Efter varje tur granskar den lilla Haiku-modellen transkriptet och avgör: ”villkoret uppfyllt – avsluta” eller ”inte uppfyllt – nästa tur”. Utvärderaren kör inga verktyg; den läser bara.

Alias för att rensa det: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Kombinationen med Plan Mode ser ut så här:

1. Aktivera Plan Mode (tryck på Shift+Tab två gånger).
2. Be: ”skapa en plan för att migrera databasen från MySQL till Postgres, spara den i plans/2026-05-21-postgres-migration.md med faser och kriterier”.
3. Granska planen, redigera den och godkänn den.
4. Avsluta Plan Mode (tryck på Shift+Tab en gång till).
5. Ange ett mål: ”slutför alla faser i plans/2026-05-21-postgres-migration.md, kryssa av rutorna, alla tester passerar, eller stoppa efter 50 turer”.
6. Stäng laptopen och gå och lägg dig.

På morgonen kontrollerar du resultatet: antingen ”✓ målet uppnått” eller ”◎ stoppade efter 50 turer”, tillsammans med en historik över vad som gjordes.

Det finns tre viktiga regler för /goal, annars slösar du tokens:

Regel 1: Ett mätbart slutläge. ”Få det att se snyggt ut” är dåligt. ”npm test returnerar 0, npm run lint returnerar 0 och en post har lagts till i CHANGELOG.md” är bra.

Regel 2: Uttrycklig verifiering. Villkoret ska hänvisa till något som går att verifiera: ett kommando, en fil eller en slutpunkt. Inte ”allt fungerar”, utan ”curl localhost:3000/api/users returnerar 200”.

Regel 3: Begränsa antalet turer. Lägg alltid till ”eller stoppa efter N turer”. Anthropic rekommenderar uttryckligen detta i dokumentationen:

Om du aktiverar /goal utan ”eller stoppa efter” kan budgeten ta slut över natten.

Vilken 4-stegscykel förvandlar Plan Mode till en ingenjörsprocess?#

Ett vanligt misstag är att fråga ”hur fixar jag det?”: Claude ger en lösning, du tillämpar den, men inget fungerar eller så blir saker värre. Det här är den ”inställsamma AI:n”: den tränas att svara snabbt, och du vill komma snabbare till koden. En 4-stegscykel löser detta.

4-stegscykeln sätter stopp för det beteendet. Den används steg för steg i en och samma Plan Mode-session:

Steg 1. Fastställ fakta utan en lösning.

Prompt: ”Jag upplever följande: [beskrivning av symtomet]. Din uppgift nu är att fastställa fakta. Alla lösningar, idéer och råd är förbjudna. Bara: vad jag observerar, vilka steg som går att reproducera, vilka data som finns tillgängliga och vilka data som saknas. Absolut stoppvillkor: FÖRESLÅ INTE lösningar; dokumentera bara diagnosen.”

Det här stoppar AI:ns första impuls: ”här är lösningen”. Claude måste stanna vid ”vad som är känt och vad som är okänt”.

Steg 2. Utveckla alternativ med föregångare.

Prompt: ”Nu när diagnosen är fastställd, hitta exempel online på hur liknande problem har lösts. Minst 3 olika tillvägagångssätt. För varje: en länk till den primära källan, en kort beskrivning samt för- och nackdelar för vår situation.”

Det här stoppar AI:ns andra impuls: ”hitta på en lösning direkt”. Vi får den att gå ut i världen och hämta tillbaka tillvägagångssätt som går att kontrollera.

Steg 3. Detaljerad plan med risker.

Prompt: ”Ta det bästa alternativet från steg 2 och lägg upp en detaljerad plan: vilka specifika filer som ska ändras, vad som ska läggas till, vad som ska tas bort, vilka tester som ska skrivas, vad som kan gå sönder och vilka risker som väntar 2-3 steg framåt.”

Det här är den välbekanta Plan-fasen, men med en skillnad: den bygger på de verifierade alternativen från steg 2, inte på Claudes gissningar.

Steg 4. Självkontroll av planen.

Prompt: ”Gör nu en obligatorisk självkontroll. Granska planen ärligt igen: finns det ställen där du dragit något ur luften och inte verifierat det mot kod, dokumentation eller ett exempel från steg 2? Markera dem i så fall och revidera planen.”

Det här är det sista filtret. Claude måste granska sitt eget resonemang och medge var den hallucinerade. Minst 2 punkter i planen brukar revideras i det här steget.

Efter de 4 stegen är planen redo att godkännas. Du går vidare till implementeringen i förvissning om att uppgiften är förstådd, alternativen har vägts och riskerna har övervägts.

Metoden är avsedd för att diagnostisera svåra buggar och fatta arkitekturbeslut där kostnaden för ett misstag är hög. Tillämpad på Plan Mode undanröjer den det största problemet för vibe-kodare: ”AI:n gav mig en lösning, jag tillämpade den och allt gick sönder.”

Vilka 5 färdiga prompter fungerar i Plan Mode för vanliga uppgifter?#

Mall 1. Refaktorering av en 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.

Mall 2. Databasmigrering.

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?

Mall 3. Lägga till 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?

Mall 4. Skriva tester.

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?

Mall 5. Felsökning av ett komplext fel.

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: documentation, official product documentation, and official sources.
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?

Kopiera varje mall, ersätt {parameters} med dina egna och klistra in den i Claude Code i Plan Mode. Resultatet blir en fungerande plan i plans/ som du godkänner och använder vid implementeringen.

Plan Mode jämfört med normalläge: vilket ska du välja?#

Anthropic säger det direkt i sin dokumentation:

Hoppa över en separat plan bara när den faktiska diffen är liten, förstådd och har låg risk. Planera när du behöver hitta tillvägagångssättet eller samordna riskfyllda komponentändringar. Kända filnamn eller ett mål sammanfattat i en mening tar inte bort risker för migrering, autentisering eller dataintegritet.

Beslutstabell:

Fråga före lägesvalet om tillvägagångssätt, bieffekter och verifiering är förstådda. Arbeta direkt på en liten, lokal ändring med låg risk och självklar kontroll. Planera först vid osäkerhet, obekant kod, migrering, autentisering eller samordning över komponenter — även om du redan kan namnge alla 3-5 berörda filer.

Hur kombinerar du Plan Mode + CLAUDE.md + subagenter för tillförlitligt arbete?#

CLAUDE.md är en fil som Claude läser i början av varje session, även i Plan Mode. Om CLAUDE.md säger ”hårdkoda aldrig datum; hämta dem alltid från databasen” kommer planen aldrig att föreslå hårdkodning. Utan en sådan regel kan planen föreslå vad som helst.

Kombinationen fungerar så här:

Lager 1. CLAUDE.md anger reglerna.

Filen anger projektets teknikstack, arkitekturprinciper, förbud (”använd inte föråldrade API:er”) och krav (”alla e-postmeddelanden ska använda en delad layout”). Utförlig guide: Så konfigurerar du CLAUDE.md.

Lager 2. Plan Mode tillämpar reglerna på uppgiften.

När du aktiverar Plan Mode och ber ”lägg till OAuth” läser Claude CLAUDE.md, ser reglerna (”lagra token i Redis, inte i databasen”) och tar genast hänsyn till dem i planen. Planen följer projektets arkitektur.

Lager 3. Subagenter delar upp arbetet.

Om planen är uppdelad i faser kan varje fas tilldelas en separat subagent. Varje subagent arbetar i sitt eget kontextfönster utan att belasta huvudfönstret. Planen i plans/ är fortsatt den centrala källan till sanningen: subagenter läser den, genomför sin fas och uppdaterar kryssrutorna.

Vilka 7 misstag förstör Plan Mode?#

Misstag 1. Planen finns bara i chatten.

Symptom: du skrev en plan, stängde fönstret och behöver återkomma nästa dag – men det finns ingenting kvar; kontexten är borta. Lösning: spara alltid planen i plans/YYYY-MM-DD-feature-name.md i kodförrådet. Chatten är ett skrivbord; filen är ett arkiv.

Misstag 2. Alla uppgifter ligger i en chatt.

Symptom: i en session diskuterar du autentisering, sedan en migrering, sedan UI-design och därefter en bugg. Kontextfönstret blir ”uppblåst” och Claude glömmer tidigare saker. Lösning: en uppgift – en konversation. Klar med planen? Stäng fönstret. Ska du börja implementera? Öppna ett nytt.

Misstag 3. En plan på 3000 rader utan faser.

Symptom: det finns en plan, men inga kryssrutor eller avdelningar. Det går inte att avgöra vad som är gjort och vad som återstår. Det går inte att delegera. Lösning: dela upp varje plan i 3-7 faser. Varje fas är en lista med kryssrutor och konkreta åtgärder.

Misstag 4. Ingen grundlig research före planen.

Symptom: Claude föreslår en lösning direkt eftersom du inte bad den leta efter föregångare. En vecka senare upptäcker du att det länge har funnits ett bättre tillvägagångssätt i open source. Lösning: steg 2 i 4-stegscykeln – be Claude hitta 2-3 exempel online innan den skapar en plan.

Misstag 5. Den inställsamma AI:n ger en lösning utan diagnos.

Symptom: du frågar ”hur fixar jag fel X?”, Claude ger en lösning, du tillämpar den och inget fungerar eller så blir det värre. Lösning: börja alltid med ”fastställ fakta; lösningar är förbjudna”. Gå vidare till alternativen först efter diagnosen.

Misstag 6. Självkontrollen hoppas över.

Symptom: planen ser rimlig ut, men innehåller 2-3 antaganden som ”dragits ur luften” (ett påhittat bibliotek, ett API som inte finns eller fel version). Implementeringen fallerar på de punkterna. Lösning: steg 4 i 4-stegscykeln – be Claude ärligt granska sin plan igen och flagga antaganden.

Misstag 7. Vaga villkor i /goal.

Symptom: du anger /goal make it look nice, låter det köra över natten och vaknar till en förbrukad kvot på $200. Lösning: använd endast mätbara villkor med ett verifieringskommando och ett obligatoriskt ”eller stoppa efter N turer”. Inget ”gör det bra” eller ”putsa till det”.

Det åttonde misstaget, som vibe-kodare oftast gör, är att bortse från själva idén med en plans/-mapp. Plan Mode utan en plans/-mapp är ingen metod; det är en leksak. Om du använder Plan Mode men inte skapar filer får du 10% av dess möjligheter.

Vad bör du göra efter din första erfarenhet av Plan Mode?#

Tre konkreta steg i stigande svårighetsgrad:

Steg 1. Konfigurera CLAUDE.md om du inte redan har en.

Utan CLAUDE.md fungerar Plan Mode ”i ett vakuum” – Claude känner inte till projektets regler och föreslår planer som bryter mot arkitekturen. Fullständig guide: Så konfigurerar du CLAUDE.md. En minimal CLAUDE.md är 50-80 rader som beskriver teknikstacken, reglerna och förbuden. Längden är mindre viktig. Det är specificiteten som spelar roll.

Steg 2. Skapa en plans/-mapp i kodförrådet.

Lägg till en plans/-mapp i projektets rot. Kom överens om ett namnformat: YYYY-MM-DD-feature-name.md. Varje plan får en egen fil. Efter en månad har du 20-30 filer; efter sex månader 100+. Det här är en levande historik över projektets beslut.

Steg 3. Prova /goal på en uppgift.

Välj en uppgift som du vanligtvis gör för hand i 30-40 minuter. Aktivera Plan Mode, skapa en plan och spara den i plans/. Avsluta Plan Mode. Ange /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Stäng laptopen i en timme och gör något annat. Kom tillbaka och kontrollera resultatet.

De tre stegen är minimum. Det här byggs upp gradvis; försök inte sätta ihop allt på en kväll. Börja med CLAUDE.md, lägg till plans/ efter en vecka och prova /goal över natten efter en månad.

När du är redo kan du träffa Ailoot.