Plan Mode a Claude Code-ban: lépésről lépésre útmutató és 4 fázis 2026-ban

További útmutatók az Ailoot dokumentációjában találhatók.

Mi az a Plan Mode, és miért nem elég önmagában?#

Normál módban a Claude Code azonnal kódot ír, és ha nem figyelsz, váratlanul sok fájlt érintő diffet kaphatsz. A Plan Mode megfordítja a lépések sorrendjét: először kutatás és tervezés, aztán jóváhagyás, majd változtatások.

Az Anthropic hivatalos dokumentációja így írja le a Plan Mode-ot:

Egyszerűnek hangzik, de a munka alapvető ritmusváltását rejti. A Plan Mode megváltoztatja a munkavégzés ütemét: előbb megállapodunk, aztán cselekszünk. Ez módváltás, nem kozmetikai finomhangolás. A vibe coderek problémája az, hogy az AI-ügynökök hajlamosak elkapkodni a munkát. Ha azt kéred, „Adj hozzá Google-hitelesítést”, normál módban Claude egy perc alatt megírja a kódot, de a fájlok fele rossz lesz. Plan Mode-ban ugyanez a kérés szöveges tervvé válik, amelyet két perc alatt elolvashatsz és kijavíthatsz, mielőtt bárki a kódhoz nyúlna.

Van egy csapda, amelyről a nemzetközi útmutatók nem írnak. A Plan Mode önmagában gyenge eszköz: a terv csak az aktuális beszélgetésben létezik. Zárd be az ablakot, és a terv elveszik. Nem adhatod át egy másik ügynöknek. Nincsenek verziók és előzmények. Ha a feladat nagy (egy 30 fájlból álló modul refaktorálása, migráció új adatbázisra), a terv hamar eléri a kontextusablak határát, és romlani kezd a minősége.

Ezért működik jól együtt a Plan Mode és a repóban lévő plans/ mappa. A terv plans/2026-05-21-google-oauth.md néven kerül mentésre, fázisokra és jelölőnégyzetekre bontva, így bármelyik következő ügynök folytathatja a munkát. Így működik a kontextusmérnökség—a kontextus kezelése a prompt előtt, nem közben.

Hogyan aktiválható a Plan Mode a Claude Code-ban?#

A leggyorsabb megoldás munkamenet közben a billentyűzet használata:

Shift+Tab           # váltás a módok között: default → acceptEdits → plan

Két megnyomás után megjelenik a terminál alján a ⏸ plan mode on jelzés. A harmadik megnyomással visszatérsz a normál módba. Ez a legkényelmesebb módszer—menet közben bekapcsolhatod, amikor látod, hogy a feladat kezd megnőni.

A második módszer, hogy egyetlen prompt elé előtagot teszel:

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

Ez akkor hasznos, ha auto-accept módban vagy, és nem szeretnéd az egész munkamenetre megváltoztatni a beállítást. Egy kérés Plan Mode-ban, aztán a munka a megszokott módon folytatódik.

A harmadik módszer a munkamenet indításakor használható:

claude --permission-mode plan

Akkor használd, ha előre tudod, hogy egy feladathoz tervezés szükséges. Például nagyobb refaktorálás vagy migráció előtt.

A negyedik módszer, hogy alapértelmezettként állítod be a projekt .claude/settings.json fájljában:

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

Mikor hasznos ez? Ha a csapat egy összetett rendszeren dolgozik, ahol bármely változtatás hatással lehet a szomszédos modulokra. Ilyenkor az alapértelmezett Plan Mode megóv mindenkit a véletlen változtatásoktól.

Egy ötödik, gyakran figyelmen kívül hagyott trükk: a Ctrl+G megnyitja a tervet egy szövegszerkesztőben. Akkor használd, ha a terv már majdnem jó, de át kell fogalmaznod 2-3 pontot vagy hozzá kell adnod egy megkötést. Szerkeszd kézzel, mentsd el, és Claude az általad módosított verzióval folytatja.

Mi az Anthropic kanonikus 4 fázisa a Plan Mode-ban: Explore, Plan, Implement, Commit?#

Sok útmutató 3 fázist (Explore-Plan-Execute) vagy csak 2-t (Plan-Implement) mutat be. Ezek egyszerűsítések. Az Anthropic hivatalos beváltgyakorlat-útmutatója pontosan 4 fázist ír le. A különbség számít: ha a Commit külön fázis, rögzíted az eredményt, nem pedig ott hagyod úgy, hogy „még csináltam pár módosítást, majd később commitolok”—ez az elveszett munka leggyakoribb forrása.

Minél pontosabb a terv, annál kevesebb iterációra van szükség a megvalósítás során. Ha 10 percet szánsz a tervre, a megvalósítás egy promptba kerül. Ha egy perc alatt vázolod fel a tervet, a megvalósítás egy órányi javítást igényel majd.

Így néz ki a 4 fázis Google OAuth hozzáadásakor (példa az Anthropic Docsból):

A promptok fázisonként is eltérnek. Explore-ban: „olvasd el a /src/auth könyvtárat, és értsd meg, hogyan kezeljük a munkameneteket és a bejelentkezést”. Planban: „Google OAuthot szeretnék hozzáadni. Mely fájlokat kell módosítani? Készíts tervet”. Implementben: „valósítsd meg a terved szerinti OAuth-folyamatot, írj teszteket, futtasd a tesztcsomagot, és javítsd ki a hibákat”. Commitban: „készíts leíró commitot, és nyiss PR-t”.

Fontos árnyalat: a Plan Mode nem akadályozza meg Claude-ot abban, hogy kutatási céllal parancsokat futtasson. A Read, LS, Glob, Grep, web fetch és a feltárást szolgáló shell-parancsok engedélyezettek. Csak az Edit, a Write és minden fájlrendszert módosító művelet tilos. Ez azt jelenti, hogy Claude elolvashatja a projekt struktúráját, futtathat git log parancsot, és megnézheti a teszteket—de nem tud véletlenül semmit megváltoztatni.

Hogyan olvasd el Claude tervét, és hogyan döntsd el, jóváhagyod-e?#

Amikor Claude elkészít egy tervet, a következő lépésekhez az alábbi lehetőségeket mutatja:

• Jóváhagyás és indítás automatikus módban
• Jóváhagyás és a szerkesztések elfogadása
• Jóváhagyás és minden szerkesztés kézi átnézése
• Tervezés folytatása visszajelzéssel
• Pontosítás Ultraplannel (böngészős átnézés)

A Plan Mode fő készsége, hogy tudd, jóvá kell-e hagyni a tervet. Könnyen előfordul, hogy automatikusan megnyomod az „Approve” gombot, majd commitokat kell visszavonnod. A hízelgő AI gyors választ akar adni, te pedig gyorsan a kódhoz szeretnél jutni. Mindketten tévedtek.

Egy jó terv 7 kritériumnak felel meg:

1. Konkrét fájlnevek. Ne az álljon benne, hogy „frissítem az authot”, hanem ez: „Módosítom a src/auth/login.ts:42-58 fájlt, létrehozom a src/auth/oauth-callback.ts fájlt, és frissítem a src/auth/session.ts:103 fájlt.”
2. Meg van adva a sorrend. A terv fázisokra vagy lépésekre oszlik, nem annyit mond, hogy „majd valahogy elvégzem az egészet”.
3. Meg vannak nevezve a külső függőségek. Ha a feladathoz új könyvtár kell, szerepel a listán. Ha környezeti változókra van szükség, azok is szerepelnek.
4. Fel vannak sorolva a kockázatok. A jó terv kimondja: „A migráció megszakíthatja a meglévő munkameneteket; ellenőrizni kell X-et.” A rossz terv hallgat a mellékhatásokról.
5. Vannak sikerkritériumok. „A test/auth tesztek sikeresek, a linter hibátlan, és a fejlesztői szerver hiba nélkül elindul.”
6. Nincsenek „a semmiből kitalált” feltételezések. Ha Claude azt mondja: „A Z könyvtárat használom”, ellenőrizd: tényleg telepítve van a projektben? Ha az AI találta ki, látni fogod, hogy nem szerepel a package.json fájlban.
7. A terv elfér a képernyőn. Ha Claude terve egy egyszerű funkcióhoz 200 soros, a feladat valószínűleg túl nagy egyetlen tervhez. Bontsd részekre.

Ha a terv nem felel meg az ellenőrzésnek, három lehetőséged van:

• Tervezés folytatása visszajelzéssel—adj Claude-nak konkrét megjegyzést arról, mi nem tetszik, és ő átírja a tervet.
• Ctrl+G—nyisd meg a tervet egy szerkesztőben, módosítsd kézzel, és mentsd el. Claude a te verzióddal folytatja.
• Pontosítás Ultraplannel—a terv átkerül a Claude Code webes böngészős módjába, ahol átnézed a részeket és megjegyzéseket fűzhetsz hozzájuk, majd helyben vagy a felhőben futtathatod.

Ha az implementálás közben valami rosszul alakul, ne erőltesd. Térj vissza a Plan Mode-ba, és írd át a tervet. Ez 10-szer olcsóbb, mint később visszavonni 40 commitot.

Plan Mode + plans/ mappa: kombináció hosszú kontextushoz#

A Plan Mode a Claude Code egyik módja. A plans/ mappa az erre épülő módszertan része. Ha mappa nélkül használod a Plan Mode-ot, egy óra munka után elérheted a határait.

Így működik a dolog. Claude kontextusablaka a munkamenet memóriája. Opus 4.7-ben 1 millió tokent tud befogadni, de ez a teljes beszélgetésed kapacitása. Ha egyetlen beszélgetésben megtervezel egy összetett feladatot, aztán megkéred Claude-ot, hogy valósítsa meg, majd megbeszélsz egy hibát, aztán valami mást is, az ablak „felfúvódik”. Claude elkezdi elfelejteni a korai döntéseket, összekeveri a kontextusokat, és újra felteszi a kérdéseket.

A megoldás az aranyszabály: egy feladat—egy beszélgetés.

Így csináld:

1. 1. beszélgetés—terv készítése. Kapcsold be a Plan Mode-ot, írd le a feladatot, és Claude elkészíti a tervet. Mentsd a tervet ide: plans/2026-05-21-feature-name.md. Zárd be az ablakot.
2. 2. beszélgetés—felosztás fázisokra. Nyiss új csevegést. Kérd meg: „vedd a plans/2026-05-21-feature-name.md fájlt, és bontsd fázisokra.” Mentsd el a frissített fájlt.
3. 3. beszélgetés—az 1. fázis megvalósítása. Nyiss új csevegést. Kérd meg: „valósítsd meg a plans/2026-05-21-feature-name.md 1. fázisát, és jelöld be a tételeket, ahogy elkészülnek.” Zárd be az ablakot.
4. 4. beszélgetés—a 2. fázis megvalósítása. Ugyanígy járj el.

Mit nyersz ezzel? Minden beszélgetés kontextusablaka friss marad. A 3. fázisban dolgozó Claude nem ismeri az 1. fázis részleteit, de ismeri a tervet, mert a plans/ fájl ott van a repóban. Bármelyik következő ügynök (legyen az alügynök, új munkamenet vagy /goal-lal futó folyamat) átveheti a tervet, és folytathatja a munkát.

A megközelítések összehasonlítása:

Minden funkciónak saját tervfájlja van. Ha három hónappal később fel kell idézned, miért választottál egy fizetési szolgáltatót egy másik helyett, megnyithatod a vonatkozó tervet, és elolvashatod a döntések előzményeit: mit beszéltek meg, milyen lehetőségeket mérlegeltek, és miért ezt az utat választották.

Ezek élő munkatervek; a statikus dokumentáció néhány hónap alatt elavul.

Hogyan dolgozhat Claude alvás közben a Plan Mode és a /goal segítségével?#

A hosszú AI-munkamenetek fő korlátja nem maga a modell, hanem az ember, aki megnyomja az Entert. Valahányszor Claude a forduló végére ér, megvárja a válaszodat. A /goal megszünteti ezt a várakozást.

A szintaxis egyszerű:

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

A feltétel legfeljebb 4000 karakter hosszú lehet. Munkamenetenként egy goal állítható be. Minden forduló után a Haiku mini-modell átnézi az átiratot, és eldönti: „feltétel teljesült—befejezés” vagy „nem teljesült—következő forduló”. Az evaluator nem hív eszközöket; csak olvas.

A törléséhez használható aliasok: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

A Plan Mode-dal együtt így néz ki:

1. Kapcsold be a Plan Mode-ot (nyomd meg kétszer a Shift+Tab billentyűt).
2. Kérd meg: „készíts tervet az adatbázis MySQL-ről Postgresre történő migrálásához, mentsd a plans/2026-05-21-postgres-migration.md fájlba fázisokkal és kritériumokkal.”
3. Nézd át a tervet, szerkeszd, majd hagyd jóvá.
4. Lépj ki a Plan Mode-ból (nyomd meg még egyszer a Shift+Tab billentyűt).
5. Állíts be egy goalt: „fejezd be a plans/2026-05-21-postgres-migration.md fájlban szereplő összes fázist, jelöld be a négyzeteket, minden teszt sikeres legyen, vagy állj le 50 forduló után.”
6. Csukd be a laptopot, és menj aludni.

Reggel ellenőrizd az eredményt: vagy „✓ goal completed”, vagy „◎ stopped after 50 turns”, valamint a végzett munka előzményeit.

A /goal használatára három lényeges szabály vonatkozik, különben csak pazarolod a tokeneket:

1. szabály: Mérhető végállapot. A „Legyen szép a megjelenése” rossz. Az „npm test 0-val tér vissza, az npm run lint 0-val tér vissza, és bekerült egy bejegyzés a CHANGELOG.md fájlba” jó.

2. szabály: Kifejezett ellenőrzés. A feltételnek ellenőrizhető dologra kell hivatkoznia: parancsra, fájlra vagy végpontra. Ne azt mondd, hogy „minden működik”, hanem azt, hogy „a curl localhost:3000/api/users 200-at ad vissza”.

3. szabály: Korlátozd a fordulók számát. Mindig add hozzá, hogy or stop after N turns. Az Anthropic kifejezetten ezt ajánlja a dokumentációjában:

Ha úgy kapcsolod be a /goal-t, hogy nincs or stop after korlátozás, a kereted reggelre elfogyhat.

Milyen 4 lépéses ciklus alakítja a Plan Mode-ot mérnöki folyamattá?#

Gyakori hiba azt kérdezni: „hogyan javítsam meg?” Claude megoldást ad, te alkalmazod, de semmi sem működik, vagy még rosszabb lesz a helyzet. Ez az „AI-hízelgő”: gyors válaszadásra tanították, te pedig gyorsabban akarsz a kódhoz jutni. Erre egy 4 lépéses ciklus nyújt megoldást.

A 4 lépéses ciklus gátat szab ennek a működésnek. Egyetlen Plan Mode-munkamenetben, egymás után kell végrehajtani:

1. lépés. A tények megállapítása megoldás nélkül.

Prompt: „Pontosan a következő történik velem: [a tünet leírása]. Most az a feladatod, hogy megállapítsd a tényeket. Minden megoldás, ötlet és tanács tilos. Csak ezt rögzítsd: mit figyeltem meg, mely lépések reprodukálhatók, milyen adatok állnak rendelkezésre, és milyen adatok hiányoznak. Szigorú leállási feltétel: NE javasolj megoldást; csak rögzítsd a diagnózist.”

Ez megállítja az AI első ösztönét: „itt a megoldás.” Claude-nak meg kell állnia annál, hogy „mi ismert és mi ismeretlen”.

2. lépés. Lehetőségek kidolgozása példákkal.

Prompt: „Most, hogy felállítottuk a diagnózist, keress online példákat hasonló problémák megoldására. Legalább 3 különböző megközelítést. Mindegyikhez: hivatkozás az elsődleges forrásra, rövid leírás, valamint az előnyök és hátrányok a mi helyzetünkben.”

Ez megállítja az AI második ösztönét: „egy megoldás kitalálása a semmiből.” Arra késztetjük, hogy kutassa fel a valós megközelítéseket, és ellenőrizhető forrásokkal térjen vissza.

3. lépés. Részletes terv kockázatokkal.

Prompt: „Válaszd ki a 2. lépés legjobb lehetőségét, és készíts részletes tervet: mely konkrét fájlokat kell módosítani, mit kell hozzáadni vagy eltávolítani, milyen teszteket kell írni, mi romolhat el, és milyen kockázatok merülhetnek fel 2-3 lépéssel később.”

Ez az ismerős Plan fázis, egy különbséggel: a Claude találgatásai helyett a 2. lépésben ellenőrzött lehetőségekre épül.

4. lépés. A terv önellenőrzése.

Prompt: „Most végezd el a kötelező önellenőrzést. Őszintén vizsgáld felül a tervedet: van-e olyan része, amit a semmiből találtál ki, és nem ellenőriztél a kóddal, a dokumentációval vagy a 2. lépésben talált példával? Ha igen, jelöld meg, és módosítsd a tervet.”

Ez az utolsó szűrő. Claude-nak ellenőriznie kell saját érvelését, és el kell ismernie, hol hallucinált. Ebben a lépésben rendszerint legalább 2 tervpontot módosítanak.

A 4 lépés után a terv készen áll a jóváhagyásra. Nyugodtan továbbléphetsz az implementációra, tudva, hogy a feladatot megértették, a lehetőségeket mérlegelték, a kockázatokat pedig figyelembe vették.

Ez a módszertan nehéz hibák diagnosztizálására és architekturális döntések meghozatalára szolgál—olyan esetekben, amikor egy hiba sokba kerül. A Plan Mode-ra alkalmazva kiküszöböli a vibe coderek fő problémáját: „az AI adott egy megoldást, alkalmaztam, és minden elromlott.”

Melyik 5 kész prompt használható a Plan Mode-ban gyakori feladatokra?#

1. sablon. Modul refaktorálása.

Bekapcsolom a Plan Mode-ot. Feladat: a {module-name} modul refaktorálása.

1. lépés: Tanulmányozd a {module-path} modul jelenlegi felépítését. Írd le:
- mely fájlok tartoznak a modulhoz
- milyen külső függőségei vannak
- mely részek ismétlődnek
- mely függvények túl bonyolultak

2. lépés: Keress online 2-3 példát hasonló modulok refaktorálására.
Legalább 1 forrás az Anthropic hivatalos dokumentációja vagy a kapcsolódó keretrendszer dokumentációja legyen.

3. lépés: Készíts refaktorálási tervet ebbe a fájlba: plans/YYYY-MM-DD-refactor-{module}.md:
- mely fájlokat kell átnevezni
- mely függvényeket kell külön modulokba kiszervezni
- mely teszteket kell megtartani és melyeket kell átírni
- kockázatok: mi romolhat el a felhasználóknál

4. lépés: Önellenőrzés. Vannak olyan feltételezések a tervben, amelyeket „a semmiből találtál ki”?
Írd át vagy töröld őket.

2. sablon. Adatbázis-migráció.

Bekapcsolom a Plan Mode-ot. Feladat: az adatbázis migrálása {old}-ról {new}-re.

1. lépés: Tanulmányozd a jelenlegi adatbázissémát a {schema-reading-command} használatával. Írd le:
- milyen táblák vannak, és mekkorák
- milyen kapcsolatok, indexek és megkötések vannak
- hol tároljuk a migrációkat
- mely adatok kritikusak

2. lépés: Keress példákat {old → new} migrációkra éles rendszerekben.
Legalább 3 különböző megközelítés: pg_dump, dual-write, blue-green.
Mindegyiknél sorold fel az előnyöket és a kockázatokat az adatmennyiségünkre nézve.

3. lépés: Készíts migrációs tervet ebbe a fájlba: plans/YYYY-MM-DD-db-migration.md:
- fázisok (biztonsági mentés, migráció, ellenőrzés, átállás)
- az egyes fázisok sikerességi kritériumai
- visszaállítási terv arra az esetre, ha valami elromlik
- leállással vagy leállás nélkül

4. lépés: Önellenőrzés. Minden számadatot alátámaszt a dokumentáció?
Minden lépést fejben ellenőriztél a fejlesztői környezethez viszonyítva?

3. sablon. Új funkció hozzáadása.

Bekapcsolom a Plan Mode-ot. Feladat: a projekt {description} funkcióval való bővítése.

1. lépés: Tanulmányozd, hogyan működnek jelenleg hasonló funkciók a projektben.
Konkrétan nézd meg:
- {file-1}
- {file-2}
- milyen architekturális mintákat használ a projekt
- milyen teszteket írnak a hasonló funkciókhoz

2. lépés: Nézd meg, hogyan valósítják meg ezt a funkciót hasonló architektúrájú nyílt forráskódú projektekben.
Legalább 2 különböző megközelítést keress.

3. lépés: Készíts tervet ebbe a fájlba: plans/YYYY-MM-DD-feature-{name}.md:
- az új fájlok listája
- a módosítandó fájlok listája, konkrét sorokkal
- az implementáció sorrendje
- hozzáadandó tesztek
- a CLAUDE.md jövőbeli munkamenetekre vonatkozó szabályként hozzáadandó tartalma

4. lépés: Önellenőrzés. Követi a terv a projekt architektúráját?
Feltételez olyan könyvtárakat, amelyeket még nem telepítettek?

4. sablon. Tesztek írása.

Bekapcsolom a Plan Mode-ot. Feladat: a {name} modul tesztekkel való lefedése.

1. lépés: Tanulmányozd a {path} modult. Azonosítsd:
- a publikus függvényeket és azok aláírását
- a belső függvényeket, amelyeket NEM tesztelünk (implementációs részletek)
- szélső eseteket: üres bemenet, hibák, párhuzamos hozzáférés

2. lépés: Keress tesztpéldákat hasonló feladatokra
ugyanazt a keretrendszert használó népszerű nyílt forráskódú projektekben.

3. lépés: Készíts teszttervet ebbe a fájlba: plans/YYYY-MM-DD-tests-{module}.md:
- minden publikus függvényhez a tesztek listája
- milyen mockokra van szükség
- milyen fixture-ökre van szükség
- milyen ellenőrzési megközelítést alkalmazunk (assertion style)

4. lépés: Önellenőrzés. Minden teszt a viselkedést ellenőrzi, nem az implementációt?
A lefedettség a szélső esetekre is kiterjed?

5. sablon. Összetett hiba hibakeresése.

Bekapcsolom a Plan Mode-ot. Feladat: a {symptom-description} hiba okának megértése.

1. lépés: ÁLLAPÍTSD MEG A TÉNYEKET. A megoldások és ötletek tilosak. Csak ezt rögzítsd:
- mit figyelek meg (a hiba pontos szövege)
- reprodukálható lépések
- milyen adatok állnak rendelkezésre (naplók, trace-ek, könyvtárverziók)
- milyen adatok hiányoznak (mit kell még begyűjteni)

2. lépés: Keress példákat erre a hibára.
Legalább 3 forrásból: GitHub-issues, dokumentáció és más megbízható technikai források.
Mindegyikhez adj meg egy hivatkozást és röviden foglald össze a megoldást.

3. lépés: Készíts diagnosztikai tervet ebbe a fájlba: plans/YYYY-MM-DD-bug-{name}.md:
- ellenőrizendő hipotézisek (valószínűség szerinti sorrendben)
- az egyes hipotézisek ellenőrzéséhez futtatandó parancsok/scriptek
- az egyes ellenőrzések várt eredménye

4. lépés: Önellenőrzés. Vannak olyan hipotézisek a tervben, amelyeket „a semmiből találtál ki”?
Minden hipotézis az 1. lépés tényeihez kapcsolódik?

Másold le a sablonokat, cseréld le a {parameters} részeket a saját értékeidre, és illeszd be őket a Claude Code-ba Plan Mode-ban. Az eredmény egy működő terv lesz a plans/ mappában, amelyet jóváhagyhatsz és felhasználhatsz az implementációhoz.

Plan Mode vagy normál mód: melyiket válaszd?#

Az Anthropic ezt közvetlenül kimondja a dokumentációjában:

Külön tervet csak kis, megértett és alacsony kockázatú tényleges diffnél hagyj ki. Tervezz, ha fel kell deríteni a megközelítést vagy kockázatos komponensmódosításokat kell összehangolni. A fájlnevek ismerete vagy a cél egymondatos összefoglalása nem szüntet migrációs, hitelesítési vagy adatintegritási kockázatot.

Döntési táblázat:

Módválasztás előtt kérdezd meg, érted-e a megközelítést, mellékhatásokat és ellenőrzést. Kis, helyi, alacsony kockázatú, nyilvánvalóan ellenőrizhető módosításon dolgozz közvetlenül. Bizonytalanságnál, ismeretlen kódnál, migrációnál, hitelesítésnél vagy komponensek összehangolásánál előbb tervezz akkor is, ha mind a 3-5 érintett fájlt meg tudod nevezni.

Hogyan kombinálható a Plan Mode + CLAUDE.md + alügynökök a megbízható munkához?#

A CLAUDE.md olyan fájl, amelyet Claude minden munkamenet elején elolvas, a Plan Mode-ot is beleértve. Ha a CLAUDE.md azt írja: „soha ne kódolj be dátumokat; mindig az adatbázisból vedd őket”, a terv soha nem javasol dátumok beégetését. Ilyen szabály nélkül bármit javasolhat.

A kombináció így működik:

1. réteg. A CLAUDE.md meghatározza a szabályokat.

A fájl megadja a projekt technológiai stackjét, az architekturális elveket, a tiltásokat („ne használj elavult API-kat”) és a követelményeket („minden e-mail egy közös elrendezést használjon”). Részletes útmutató: A CLAUDE.md beállítása.

2. réteg. A Plan Mode alkalmazza a szabályokat a feladatra.

Amikor bekapcsolod a Plan Mode-ot, és azt kéred, hogy „adj hozzá OAuthot”, Claude elolvassa a CLAUDE.md fájlt, meglátja a szabályokat („a tokeneket Redisben tárold, ne az adatbázisban”), és már a tervben figyelembe veszi őket. A terv igazodik a projekt architektúrájához.

3. réteg. Az alügynökök felosztják a munkát.

Ha a terv fázisokra oszlik, minden fázist külön alügynök kaphat meg. Mindegyik alügynök a saját kontextusablakában dolgozik, így nem zsúfolja tele a főablakot. A plans/ mappában lévő terv marad az elsődleges igazodási pont: az alügynökök elolvassák, végrehajtják a rájuk eső fázist, és frissítik a jelölőnégyzeteket.

Melyik 7 hiba teszi tönkre a Plan Mode-ot?#

1. hiba. A terv csak a csevegésben létezik.

Tünet: megírtál egy tervet, bezártad az ablakot, másnap vissza kell térned hozzá—de már semmi sincs ott, a kontextus elveszett. Megoldás: mindig mentsd a tervet a repó plans/YYYY-MM-DD-feature-name.md fájljába. A csevegés az íróasztal; a fájl az archívum.

2. hiba. Minden feladat egyetlen csevegésbe kerül.

Tünet: egy munkamenetben előbb az authról beszélsz, aztán egy migrációról, majd UI-tervezésről, végül egy hibáról. A kontextusablak „felfúvódik”, Claude pedig elfelejti a korábbiakat. Megoldás: egy feladat—egy beszélgetés. Kész a terv? Zárd be az ablakot. Kezdődik az implementáció? Nyiss újat.

3. hiba. Egy 3000 soros, fázisok nélküli terv.

Tünet: van terv, de nincsenek benne jelölőnégyzetek vagy felosztások. Lehetetlen megállapítani, mi készült el és mi nem. A delegálás lehetetlen. Megoldás: bonts minden tervet 3-7 fázisra. Minden fázis konkrét műveletekből álló jelölőnégyzetlista legyen.

4. hiba. Nincs alapos kutatás a terv előtt.

Tünet: Claude rögtönözve javasol megoldást, mert nem kérted meg, hogy keressen példákat. Egy héttel később kiderül, hogy egy jobb megoldást már régóta használnak a nyílt forráskódú projektekben. Megoldás: a 4 lépéses ciklus 2. lépésében kérd meg Claude-ot, hogy a terv elkészítése előtt keressen 2-3 példát az interneten.

5. hiba. Az AI-hízelgő diagnózis nélkül kínál megoldást.

Tünet: azt kérdezed, „Hogyan javítsam ki az X hibát?”, Claude megoldást ad, te alkalmazod, de semmi sem működik, vagy rosszabb lesz a helyzet. Megoldás: mindig ezzel kezdd: „állapítsd meg a tényeket; megoldások tilosak.” Csak a diagnózis után térj át a lehetőségekre.

6. hiba. Kimarad az önellenőrzés.

Tünet: a terv hihetőnek látszik, de 2-3 „a semmiből kitalált” feltételezést tartalmaz (kitalált könyvtárat, nem létező API-t vagy rossz verziót). Ezeknél az implementáció elbukik. Megoldás: a 4 lépéses ciklus 4. lépésében kérd meg Claude-ot, hogy őszintén ellenőrizze újra a tervét, és jelölje meg a feltételezéseket.

7. hiba. Homályos feltételek a /goal-ban.

Tünet: beállítod, hogy /goal make it look nice, futni hagyod éjszakára, és reggel azt látod, hogy elfogyott 200 dollárnyi kvóta. Megoldás: csak mérhető feltételeket használj, ellenőrző paranccsal és kötelező or stop after N turns kitétellel. Ne használj olyat, hogy „legyen jobb” vagy „csiszold még”.

A nyolcadik hiba, amelyet a vibe coderek követnek el a leggyakrabban, hogy figyelmen kívül hagyják a plans/ mappa fogalmát. A plans/ mappa nélküli Plan Mode nem módszertan, hanem játék. Ha használod a Plan Mode-ot, de nem hozol létre fájlokat, a képességeinek csak 10%-át használod ki.

Mit tegyél a Plan Mode-dal szerzett első tapasztalatod után?#

Három konkrét lépés, növekvő nehézségi sorrendben:

1. lépés. Állítsd be a CLAUDE.md fájlt, ha még nincs.

CLAUDE.md nélkül a Plan Mode „vákuumban” működik—Claude nem ismeri a projekt szabályait, és olyan terveket javasol, amelyek megtörik az architektúrát. Teljes útmutató: A CLAUDE.md beállítása. Egy minimális CLAUDE.md 50-80 sorban írja le a stacket, a szabályokat és a tiltásokat. A hossz másodlagos. A konkrétság számít.

2. lépés. Hozz létre plans/ mappát a repóban.

Adj hozzá egy plans/ mappát a projekt gyökeréhez. Állapodjatok meg a fájlnevek formátumában: YYYY-MM-DD-feature-name.md. Minden terv saját fájlt kap. Egy hónap múlva 20-30 fájlod lesz; hat hónap múlva 100+. Ez a projekt élő döntési előzménye.

3. lépés. Próbáld ki a /goal-t egy feladaton.

Válassz egy olyan feladatot, amelyet általában kézzel végzel 30-40 perc alatt. Kapcsold be a Plan Mode-ot, készíts tervet, és mentsd a plans/ mappába. Lépj ki a Plan Mode-ból. Állítsd be a /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns parancsot. Csukd be a laptopot egy órára, és foglalkozz valami mással. Térj vissza, és ellenőrizd az eredményt.

Ez a három lépés a minimum. Ez fokozatosan épül fel; ne próbáld egyetlen este alatt mindet kialakítani. Kezdd a CLAUDE.md-vel, egy hét múlva add hozzá a plans/ mappát, és egy hónap múlva próbáld ki éjszakára a /goal-t.

Ha készen állsz, ismerd meg az Ailootot.