Claude Code Plan Mode: włączanie i 4 fazy pracy

Dodatkowe instrukcje znajdziesz w dokumentacji Ailoot.

Czym jest Tryb Plan i dlaczego sam w sobie nie wystarcza?#

W zwykłym trybie Claude Code od razu pisze kod, a jeśli nie pilnujesz jego pracy, możesz nagle dostać diff obejmujący wiele plików. Tryb Plan odwraca kolejność: najpierw analiza i planowanie, potem zatwierdzenie, a dopiero później zmiany.

Anthropic opisuje Tryb Plan w oficjalnej dokumentacji tak:

Brzmi prosto, ale kryje się za tym zasadnicza zmiana. Tryb Plan zmienia rytm pracy: najpierw uzgodnienia, potem działanie. To zmiana trybu, a nie kosmetyczna poprawka. Problem dla osób programujących „na wyczucie” polega na tym, że agenci AI mają tendencję do pośpiechu. Jeśli w zwykłym trybie poprosisz: „Dodaj uwierzytelnianie Google”, Claude napisze kod w minutę, ale połowa plików będzie niewłaściwa. W Trybie Plan ta sama prośba zamienia się w tekstowy plan, który możesz przeczytać w dwie minuty i poprawić, zanim zostanie zmieniony jakikolwiek kod.

Oto pułapka, o której nie piszą międzynarodowe poradniki. Sam Tryb Plan jest słabym narzędziem: plan istnieje tylko w bieżącej rozmowie. Zamknij okno, a plan zniknie. Nie możesz przekazać go innemu agentowi. Nie ma wersji ani historii. Jeśli zadanie jest duże (refaktoryzacja modułu złożonego z 30 plików, migracja do nowej bazy danych), plan szybko dobije do limitu okna kontekstu i zacznie tracić na jakości.

Dlatego Tryb Plan dobrze współpracuje z folderem plans/ w repozytorium. Plan zostaje zapisany jako plans/2026-05-21-google-oauth.md, podzielony na fazy z polami wyboru, a kolejny agent może go podjąć. Tak działa inżynieria kontekstu — zarządzanie kontekstem przed poleceniem, a nie w jego trakcie.

Jak włączyć Tryb Plan w Claude Code?#

Najszybszy sposób podczas sesji to użycie klawiatury:

Shift+Tab           # przełącza między trybami: default → acceptEdits → plan

Po dwóch naciśnięciach u dołu terminala pojawi się wskaźnik ⏸ plan mode on. Trzecie naciśnięcie przywraca zwykły tryb. To najwygodniejsza metoda — możesz włączać go na bieżąco, gdy widzisz, że zadanie się rozrasta.

Drugi sposób to dodanie prefiksu przed pojedynczym poleceniem:

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

Ta opcja przydaje się, gdy korzystasz z trybu automatycznego akceptowania i nie chcesz zmieniać go na całą sesję. Jedno żądanie w Trybie Plan, a potem praca toczy się jak wcześniej.

Trzeci sposób: przy uruchamianiu sesji:

claude --permission-mode plan

Użyj go, gdy wiesz z wyprzedzeniem, że zadanie wymaga planowania. Na przykład przed dużą refaktoryzacją albo migracją.

Czwarty sposób to ustawienie trybu domyślnego w pliku .claude/settings.json w projekcie:

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

Kiedy to się przydaje? Gdy zespół pracuje nad złożonym systemem, w którym każda zmiana może wpłynąć na sąsiednie moduły. Domyślny Tryb Plan chroni wtedy wszystkich przed przypadkowymi zmianami.

Często pomijany piąty trik: Ctrl+G otwiera plan w edytorze tekstu. Użyj go, gdy plan jest prawie dobry, ale trzeba przeredagować 2-3 punkty lub dodać ograniczenie. Edytuj go ręcznie, zapisz, a Claude będzie kontynuować pracę z twoją wersją.

Jakie są kanoniczne 4 fazy Anthropic w Trybie Plan: Explore, Plan, Implement, Commit?#

Wiele poradników opisuje 3 fazy (Explore-Plan-Execute) albo tylko 2 (Plan-Implement). To uproszczenia. W swoim oficjalnym przewodniku dobrych praktyk Anthropic opisuje dokładnie 4 fazy. Ta różnica ma znaczenie: osobna faza Commit sprawia, że zapisujesz wynik, zamiast poprzestać na „wprowadziłem jeszcze kilka poprawek, zatwierdzę je później” — najczęstszym źródle utraconej pracy.

Im precyzyjniejszy plan, tym mniej iteracji wymaga wdrażanie. Jeśli poświęcisz 10 minut na plan, wdrożenie zajmie jedno polecenie. Jeśli naszkicujesz plan w minutę, wdrożenie pochłonie godzinę poprawek.

Tak wyglądają 4 fazy przy dodawaniu Google OAuth (przykład z Anthropic Docs):

Polecenia są inne w każdej fazie. W Explore: „przeczytaj /src/auth i ustal, jak obsługujemy sesje i logowanie”. W Plan: „Chcę dodać Google OAuth. Które pliki trzeba zmienić? Utwórz plan”. W Implement: „wdroż przepływ OAuth zgodnie ze swoim planem, napisz testy, uruchom zestaw i napraw błędy”. W Commit: „utwórz commit z opisową wiadomością i otwórz pull request”.

Ważny szczegół: Tryb Plan nie powstrzymuje Claude przed uruchamianiem poleceń na potrzeby analizy. Dozwolone są Read, LS, Glob, Grep, pobieranie stron internetowych i polecenia powłoki służące do eksploracji. Zabronione są wyłącznie Edit, Write i wszelkie operacje zmieniające system plików. Dzięki temu Claude może odczytać strukturę projektu, uruchomić git log i przejrzeć testy — ale nie zmieni niczego przypadkiem.

Jak czytać plan Claude i zdecydować, czy go zatwierdzić?#

Po utworzeniu planu Claude wyświetla dostępne opcje:

• Zatwierdź i rozpocznij w trybie automatycznym
• Zatwierdź i zezwól na edycję
• Zatwierdź i ręcznie przeglądaj każdą edycję
• Kontynuuj planowanie, przekazując uwagi
• Udoskonal plan za pomocą Ultraplan (przegląd w przeglądarce)

Umiejętność oceny, czy zatwierdzić plan, jest kluczowa w Trybie Plan. Łatwo jest automatycznie nacisnąć „Zatwierdź”, a potem musieć wycofywać commity. AI pochlebca chce szybko odpowiedzieć, a ty chcesz szybciej przejść do kodu. Oboje się mylicie.

Dobry plan spełnia 7 kryteriów:

1. Konkretne nazwy plików. Nie „zaktualizuję uwierzytelniania”, ale „zmienię src/auth/login.ts:42-58, utworzę src/auth/oauth-callback.ts i zaktualizuję src/auth/session.ts:103”.
2. Określona sekwencja. Plan jest podzielony na fazy lub kroki, a nie sprowadza się do „gdzieś to wszystko zrobię”.
3. Wymienione zależności zewnętrzne. Jeśli zadanie wymaga nowej biblioteki, jest ona wymieniona. Jeśli potrzebne są zmienne środowiskowe, również są wymienione.
4. Wymienione ryzyka. Dobry plan mówi: „Migracja może popsuć istniejące sesje; trzeba sprawdzić X”. Zły przemilcza skutki uboczne.
5. Określone kryteria sukcesu. „Testy test/auth przechodzą, linter nie zgłasza błędów, a serwer deweloperski uruchamia się bez błędów”.
6. Brak założeń „wyciągniętych z powietrza”. Jeśli Claude mówi „użyję biblioteki Z”, sprawdź: czy w ogóle została zainstalowana w projekcie? Jeśli AI ją zmyśliło, zobaczysz, że nie ma jej w package.json.
7. Plan mieści się na ekranie. Jeśli prosty plan funkcji zajmuje 200 wierszy, zadanie jest prawdopodobnie zbyt duże na jeden plan. Podziel je na części.

Gdy plan nie przechodzi weryfikacji, masz trzy możliwości:

• Kontynuuj planowanie, przekazując uwagi — przekaż Claude konkretny komentarz o tym, co ci się nie podoba, a przepisze plan.
• Ctrl+G — otwórz plan w edytorze, ręcznie go zmień i zapisz. Claude będzie kontynuować pracę z twoją wersją.
• Udoskonal plan za pomocą Ultraplan — plan trafia do trybu przeglądarkowego Claude Code w sieci, gdzie możesz przeglądać sekcje i komentować, a następnie uruchomić go lokalnie albo w chmurze.

Jeśli coś pójdzie nie tak w trakcie wdrażania, nie forsuj tego. Wróć do Trybu Plan i przepisz plan. To 10 razy tańsze niż późniejsze wycofywanie 40 commitów.

Tryb Plan + folder plans/: połączenie przy długim kontekście#

Tryb Plan jest trybem Claude Code. Folder plans/ to metodologia zbudowana na jego podstawie. Jeśli używasz Trybu Plan bez folderu, po godzinie pracy dotrzesz do limitu.

Oto logika. Okno kontekstu Claude jest pamięcią sesji. W Opus 4.7 mieści 1 milion tokenów, ale to objętość całej rozmowy. Jeśli w jednej rozmowie zaplanujesz złożone zadanie, potem poprosisz o wdrożenie, następnie omówisz błąd i jeszcze coś innego, okno stanie się „napompowane”. Claude zacznie zapominać wcześniejsze decyzje, mylić konteksty i ponownie zadawać pytania.

Rozwiązaniem jest złota zasada: jedno zadanie — jedna rozmowa.

Oto jak to zrobić:

1. Rozmowa 1 — przygotuj plan. Włącz Tryb Plan, opisz zadanie, a Claude utworzy plan. Zapisz go w plans/2026-05-21-feature-name.md. Zamknij okno.
2. Rozmowa 2 — podziel go na fazy. Otwórz nowy czat. Poproś: „weź plans/2026-05-21-feature-name.md i podziel go na fazy”. Zapisz zaktualizowany plik.
3. Rozmowa 3 — wdrażaj fazę 1. Otwórz nowy czat. Poproś: „wdrażaj Fazę 1 z plans/2026-05-21-feature-name.md i zaznaczaj elementy po ich ukończeniu”. Zamknij okno.
4. Rozmowa 4 — wdrażaj fazę 2. Zrób to samo.

Co ci to daje? Okno kontekstu każdej rozmowy pozostaje świeże. Claude w fazie 3 nie zna szczegółów fazy 1, ale zna plan, bo plik plans/ jest w repozytorium. Każdy kolejny agent (podagent, nowa sesja albo uruchomienie przez /goal) może podjąć plan i kontynuować pracę.

Porównanie podejść:

Każda funkcja ma własny plik z planem. Gdy po trzech miesiącach trzeba sobie przypomnieć, dlaczego wybrano jednego dostawcę płatności zamiast innego, można otworzyć odpowiedni plan i przeczytać historię decyzji: co omówiono, jakie opcje rozważano i dlaczego wybrano właśnie tę ścieżkę.

To żywe plany pracy; dokumentacja statyczna starzeje się w ciągu kilku miesięcy.

Jak sprawić, by Claude pracował podczas twojego snu za pomocą Trybu Plan i /goal?#

Głównym ograniczeniem długich sesji AI nie jest sam model, lecz osoba naciskająca Enter. Za każdym razem, gdy Claude kończy turę, czeka na twoją odpowiedź. /goal usuwa to oczekiwanie.

Składnia jest prosta:

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

Warunek może mieć do 4000 znaków. Jedna wartość celu na sesję. Po każdej turze mini-model Haiku analizuje transkrypcję i decyduje: „warunek spełniony — zakończ” albo „niespełniony — kolejna tura”. Ewaluator nie wywołuje narzędzi; tylko czyta.

Aliasy do wyczyszczenia celu: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Połączenie z Trybem Plan wygląda tak:

1. Włącz Tryb Plan (naciśnij dwa razy Shift+Tab).
2. Poproś: „utwórz plan migracji bazy danych z MySQL do Postgres, zapisz go w plans/2026-05-21-postgres-migration.md wraz z fazami i kryteriami”.
3. Przejrzyj plan, edytuj go i zatwierdź.
4. Wyjdź z Trybu Plan (naciśnij jeszcze raz Shift+Tab).
5. Ustaw cel: „ukończ wszystkie fazy w plans/2026-05-21-postgres-migration.md, zaznacz pola, wszystkie testy mają przechodzić albo zatrzymaj się po 50 turach”.
6. Zamknij laptop i idź spać.

Rano sprawdź wynik: albo „✓ cel osiągnięty”, albo „◎ zatrzymano po 50 turach” — wraz z historią wykonanych działań.

Istnieją trzy zasadnicze zasady dotyczące /goal, które pozwolą uniknąć marnowania tokenów:

Zasada 1: Mierzalny stan końcowy. „Zrób, żeby wyglądało ładnie” to zły warunek. Dobry brzmi: „npm test zwraca 0, npm run lint zwraca 0, a w CHANGELOG.md pojawił się wpis”.

Zasada 2: Jawna weryfikacja. Warunek powinien wskazywać coś, co można zweryfikować: polecenie, plik albo endpoint. Nie „wszystko działa”, lecz „curl localhost:3000/api/users zwraca 200”.

Zasada 3: Ograniczenie liczby tur. Zawsze dodaj „albo zatrzymaj się po N turach”. Anthropic wyraźnie zaleca w dokumentacji:

Jeśli włączysz /goal bez limitu „albo zatrzymaj się po”, budżet może zniknąć przez noc.

Jaki 4-etapowy cykl zmienia Tryb Plan w proces inżynierski?#

Częstym błędem jest pytanie „jak to naprawić?”: Claude podaje rozwiązanie, wdrażasz je, ale nic nie działa albo sytuacja się pogarsza. To „AI pochlebca”: model jest szkolony, by szybko odpowiadać, a ty chcesz szybciej przejść do kodu. Ten problem rozwiązuje 4-etapowy cykl.

4-etapowy cykl blokuje ten tryb. Stosuje się go po kolei w jednej sesji Trybu Plan:

Krok 1. Ustal fakty bez proponowania rozwiązania.

Polecenie: „Obserwuję następujące zjawisko: [opis objawu]. Twoim zadaniem jest teraz ustalenie faktów. Wszelkie rozwiązania, pomysły i porady są zabronione. Tylko: co obserwuję, jakie kroki można odtworzyć, jakie dane są dostępne i jakich danych brakuje. Twardy warunek zatrzymania: NIE proponuj rozwiązań; zapisz tylko diagnozę”.

To blokuje pierwszy odruch AI: „oto rozwiązanie”. Claude musi poprzestać na „co wiadomo, a co nie”.

Krok 2. Opracuj opcje na podstawie przykładów.

Polecenie: „Skoro diagnoza jest już ustalona, znajdź w internecie przykłady rozwiązań podobnych problemów. Co najmniej 3 różne podejścia. Dla każdego podaj link do źródła pierwotnego, krótki opis oraz zalety i wady w naszym przypadku”.

To blokuje drugi odruch AI: „wymyślę rozwiązanie na poczekaniu”. Każemy mu wyjść w świat i przynieść podejścia, które można sprawdzić.

Krok 3. Szczegółowy plan z ryzykami.

Polecenie: „Weź najlepszą opcję z Kroku 2 i rozpisz szczegółowy plan: które konkretne pliki zmienić, co dodać, co usunąć, jakie testy napisać, co może się zepsuć i jakie ryzyka pojawią się 2-3 kroki naprzód”.

To znana faza Plan, ale z jedną różnicą: opiera się na zweryfikowanych opcjach z Kroku 2, a nie na domysłach Claude.

Krok 4. Sprawdź plan samodzielnie.

Polecenie: „Teraz obowiązkowo sprawdź plan samodzielnie. Uczciwie zweryfikuj go ponownie: czy są w nim elementy wyciągnięte z powietrza, których nie sprawdzono w kodzie, dokumentacji ani przykładach z Kroku 2? Jeśli tak, oznacz je i popraw plan”.

To ostatni filtr. Claude musi sprawdzić własne rozumowanie i przyznać, w których miejscach halucynował. Zwykle na tym etapie poprawiane są co najmniej 2 elementy planu.

Po 4 krokach plan jest gotowy do zatwierdzenia. Możesz przejść do wdrażania z pewnością, że zadanie zostało zrozumiane, opcje rozważone, a ryzyka uwzględnione.

Ta metoda służy do diagnozowania trudnych błędów i podejmowania decyzji architektonicznych — tam, gdzie koszt pomyłki jest wysoki. Zastosowana w Trybie Plan eliminuje główny problem osób programujących „na wyczucie”: „AI podało rozwiązanie, wdrożyłem je i wszystko się zepsuło”.

Które 5 gotowych poleceń sprawdza się w Trybie Plan przy typowych zadaniach?#

Szablon 1. Refaktoryzacja modułu.

Włączam Tryb Plan. Zadanie: zrefaktoryzować moduł {module-name}.

Krok 1: Zbadaj obecną strukturę modułu {module-path}. Opisz:
- które pliki należą do modułu
- jakie ma zależności zewnętrzne
- które części się powtarzają
- które funkcje są zbyt skomplikowane

Krok 2: Znajdź w internecie 2-3 przykłady refaktoryzacji podobnych modułów.
Co najmniej jedno źródło musi być oficjalną dokumentacją Anthropic lub powiązanego frameworka.

Krok 3: Utwórz plan refaktoryzacji w pliku plans/YYYY-MM-DD-refactor-{module}.md:
- które pliki zmienić
- które funkcje wydzielić do osobnych modułów
- które testy zachować, a które napisać ponownie
- ryzyka: co może się zepsuć użytkownikom

Krok 4: Sprawdź plan samodzielnie. Czy zawiera jakieś założenia „wyciągnięte z powietrza”?
Popraw je albo usuń.

Szablon 2. Migracja bazy danych.

Włączam Tryb Plan. Zadanie: zmigrować bazę danych z {old} do {new}.

Krok 1: Zbadaj obecny schemat bazy danych za pomocą {schema-reading-command}. Opisz:
- jakie są tabele i jaki mają rozmiar
- jakie występują relacje, indeksy i ograniczenia
- gdzie są przechowywane migracje
- które dane są krytyczne

Krok 2: Znajdź przykłady migracji {old → new} w projektach produkcyjnych.
Co najmniej 3 różne podejścia: pg_dump, dual-write, blue-green.
Dla każdego wymień zalety i ryzyka przy naszym rozmiarze danych.

Krok 3: Utwórz plan migracji w pliku plans/YYYY-MM-DD-db-migration.md:
- fazy (kopia zapasowa, migracja, weryfikacja, przełączenie)
- kryteria sukcesu dla każdej fazy
- plan wycofania zmian na wypadek problemów
- przestój albo brak przestoju

Krok 4: Sprawdź plan samodzielnie. Czy wszystkie liczby mają potwierdzenie w dokumentacji?
Czy wszystkie kroki sprawdzono w myślach względem środowiska deweloperskiego?

Szablon 3. Dodanie nowej funkcji.

Włączam Tryb Plan. Zadanie: dodać do projektu funkcję {description}.

Krok 1: Zbadaj, jak podobne funkcje działają obecnie w projekcie.
Sprawdź w szczególności:
- {file-1}
- {file-2}
- wykorzystywane wzorce architektoniczne
- testy napisane dla podobnych funkcji

Krok 2: Sprawdź, jak ta funkcja jest wdrażana w projektach open source
z podobną architekturą. Co najmniej 2 różne podejścia.

Krok 3: Utwórz plan w pliku plans/YYYY-MM-DD-feature-{name}.md:
- lista nowych plików
- lista zmienianych plików z konkretnymi wierszami
- kolejność wdrażania
- testy do dodania
- co dodać do CLAUDE.md jako zasadę dla przyszłych sesji

Krok 4: Sprawdź plan samodzielnie. Czy jest zgodny z architekturą projektu?
Czy zakłada użycie bibliotek, które nie zostały jeszcze zainstalowane?

Szablon 4. Pisanie testów.

Włączam Tryb Plan. Zadanie: pokryć moduł {name} testami.

Krok 1: Zbadaj moduł {path}. Ustal:
- funkcje publiczne i ich sygnatury
- funkcje wewnętrzne, których NIE będziemy testować (szczegóły implementacji)
- sytuacje brzegowe: puste wejście, błędy, dostęp współbieżny

Krok 2: Znajdź przykłady testów dla podobnej klasy zadań
w popularnych projektach open source korzystających z tego samego frameworka.

Krok 3: Utwórz plan testów w pliku plans/YYYY-MM-DD-tests-{module}.md:
- listę testów dla każdej funkcji publicznej
- potrzebne atrapy
- potrzebne fixtures
- podejście do weryfikacji (styl asercji)

Krok 4: Sprawdź plan samodzielnie. Czy wszystkie testy sprawdzają zachowanie, a nie implementację?
Czy uwzględniono sytuacje brzegowe?

Szablon 5. Diagnozowanie złożonego błędu.

Włączam Tryb Plan. Zadanie: ustalić przyczynę błędu {symptom-description}.

Krok 1: USTAL FAKTY. Rozwiązania i pomysły są zabronione. Tylko:
- co obserwuję (dokładne brzmienie błędu)
- kroki pozwalające go odtworzyć
- jakie dane są dostępne (logi, ślady, wersje bibliotek)
- jakich danych brakuje (co trzeba dodatkowo zebrać)

Krok 2: Znajdź przykłady tego błędu.
Co najmniej 3 źródła: zgłoszenia GitHub, dokumentacja i inne wiarygodne źródła.
Dla każdego podaj link i krótkie podsumowanie rozwiązania.

Krok 3: Utwórz plan diagnostyczny w pliku plans/YYYY-MM-DD-bug-{name}.md:
- hipotezy do sprawdzenia (uporządkowane według prawdopodobieństwa)
- polecenia/skrypty, którymi trzeba sprawdzić każdą z nich
- oczekiwany wynik każdej weryfikacji

Krok 4: Sprawdź plan samodzielnie. Czy są w nim hipotezy „wyciągnięte z powietrza”?
Czy wszystkie hipotezy wynikają z faktów z Kroku 1?

Skopiuj każdy szablon, zastąp {parameters} własnymi wartościami i wklej go do Claude Code w Trybie Plan. W rezultacie otrzymasz plan pracy w folderze plans/, który możesz zatwierdzić i wykorzystać do wdrożenia.

Tryb Plan a zwykły tryb: który wybrać?#

Anthropic pisze o tym wprost w dokumentacji:

Wskazówki dotyczące planowania należy stosować do ryzyka i zrozumienia faktycznej zmiany. Krótki opis celu nie zastępuje oceny skutków ubocznych ani sprawdzeń.

Pomiń osobne planowanie tylko przy małym, zrozumiałym diffie niskiego ryzyka. Planuj, gdy trzeba ustalić podejście lub skoordynować ryzykowne zmiany komponentów. Znajomość nazw plików ani jednozdaniowy cel nie usuwają ryzyk migracji, uwierzytelniania czy integralności danych.

Tabela decyzyjna:

Przed wyborem trybu zapytaj, czy rozumiesz podejście, skutki uboczne i sprawdzenia. Małą, lokalną zmianę niskiego ryzyka z oczywistą kontrolą wykonaj bezpośrednio. Najpierw planuj przy niepewności, nieznanym kodzie, migracji, uwierzytelnianiu lub koordynacji komponentów, nawet gdy umiesz wymienić wszystkie 3-5 plików.

Jak połączyć Tryb Plan + CLAUDE.md + podagentów, by praca była niezawodna?#

CLAUDE.md to plik, który Claude czyta na początku każdej sesji, także w Trybie Plan. Jeśli CLAUDE.md mówi „nigdy nie wpisuj dat na stałe; zawsze pobieraj je z bazy danych”, plan nigdy nie zasugeruje wpisania daty na stałe. Jeśli nie ma takiej zasady, plan może zasugerować cokolwiek.

To połączenie działa tak:

Warstwa 1. CLAUDE.md ustala zasady.

Plik określa stos projektu, zasady architektoniczne, zakazy („nie używaj przestarzałych API”) i wymagania („wszystkie wiadomości e-mail muszą korzystać ze wspólnego układu”). Szczegółowy poradnik: Jak skonfigurować CLAUDE.md.

Warstwa 2. Tryb Plan stosuje zasady do zadania.

Gdy włączysz Tryb Plan i poprosisz „dodaj OAuth”, Claude przeczyta CLAUDE.md, zobaczy zasady („przechowuj tokeny w Redisie, nie w bazie danych”) i od razu uwzględni je w planie. Plan będzie zgodny z architekturą projektu.

Warstwa 3. Podagenci dzielą pracę.

Jeśli plan jest podzielony na fazy, każdą można przydzielić osobnemu podagentowi. Każdy podagent pracuje we własnym oknie kontekstu, nie zaśmiecając głównego. Plan w plans/ pozostaje centralnym źródłem prawdy: podagenci czytają go, realizują swoją fazę i aktualizują pola wyboru.

Jakie 7 błędów psuje Tryb Plan?#

Błąd 1. Plan istnieje tylko na czacie.

Objaw: napisałeś plan, zamknąłeś okno i musisz do niego wrócić następnego dnia, ale niczego tam nie ma — kontekst zniknął. Rozwiązanie: zawsze zapisuj plan w repozytorium w pliku plans/YYYY-MM-DD-feature-name.md. Czat to biurko; plik to archiwum.

Błąd 2. Wszystkie zadania są w jednym czacie.

Objaw: podczas jednej sesji omawiasz uwierzytelnianie, potem migrację, projekt UI, a następnie błąd. Okno kontekstu zostaje „napompowane”, a Claude zapomina wcześniejsze informacje. Rozwiązanie: jedno zadanie — jedna rozmowa. Skończyłeś plan? Zamknij okno. Zaczynasz wdrażanie? Otwórz nowe.

Błąd 3. Jeden plan na 3000 wierszy bez faz.

Objaw: plan istnieje, ale nie ma pól wyboru ani podziału. Nie wiadomo, co jest zrobione, a co nie. Nie da się delegować pracy. Rozwiązanie: podziel każdy plan na 3-7 faz. Każda faza powinna być listą pól wyboru z konkretnymi działaniami.

Błąd 4. Brak dogłębnego researchu przed planem.

Objaw: Claude proponuje rozwiązanie na poczekaniu, bo nie poprosiłeś go o znalezienie przykładów. Tydzień później odkrywasz, że open source od dawna ma lepsze podejście. Rozwiązanie: Krok 2 cyklu 4-etapowego — poproś Claude o znalezienie w internecie 2-3 przykładów, zanim utworzy plan.

Błąd 5. AI pochlebca podaje rozwiązanie bez diagnozy.

Objaw: pytasz „jak naprawić błąd X?”, Claude podaje rozwiązanie, wdrażasz je, a nic nie działa albo sytuacja się pogarsza. Rozwiązanie: zawsze zaczynaj od „ustal fakty; rozwiązania są zabronione”. Dopiero po diagnozie przejdź do opcji.

Błąd 6. Pominięcie samodzielnej weryfikacji.

Objaw: plan wygląda wiarygodnie, ale zawiera 2-3 założenia „wyciągnięte z powietrza” (zmyśloną bibliotekę, nieistniejące API albo błędną wersję). Wdrożenie rozbija się o te punkty. Rozwiązanie: Krok 4 cyklu 4-etapowego — poproś Claude, by uczciwie sprawdził ponownie swój plan i wskazał założenia.

Błąd 7. Niejasne warunki w /goal.

Objaw: ustawiasz /goal make it look nice, zostawiasz go na noc, a rano okazuje się, że wykorzystano 200 $ limitu. Rozwiązanie: używaj wyłącznie mierzalnych warunków z poleceniem weryfikującym i obowiązkową klauzulą or stop after N turns. Żadnego „zrób to dobrze” ani „dopracuj”.

Ósmy błąd, który osoby programujące „na wyczucie” popełniają najczęściej, to ignorowanie samej koncepcji folderu plans/. Tryb Plan bez folderu plans/ to nie metodologia, tylko zabawka. Używając Trybu Plan bez tworzenia plików, otrzymujesz 10% jego możliwości.

Co zrobić dalej po pierwszym doświadczeniu z Trybem Plan?#

Oto trzy konkretne kroki, uporządkowane według rosnącego poziomu trudności:

Krok 1. Skonfiguruj CLAUDE.md, jeśli jeszcze go nie masz.

Bez CLAUDE.md Tryb Plan działa „w próżni” — Claude nie zna zasad projektu i proponuje plany łamiące architekturę. Pełny poradnik: Jak skonfigurować CLAUDE.md. Minimalny CLAUDE.md ma 50-80 wierszy i opisuje stos, zasady oraz zakazy. Długość jest drugorzędna. Liczy się konkret.

Krok 2. Utwórz folder plans/ w repozytorium.

Dodaj folder plans/ w głównym katalogu projektu. Ustal format nazw: YYYY-MM-DD-feature-name.md. Każdy plan trafia do osobnego pliku. Po miesiącu będziesz mieć 20-30 plików, a po sześciu miesiącach ponad 100. To żywa historia decyzji projektu.

Krok 3. Wypróbuj /goal przy jednym zadaniu.

Wybierz zadanie, które zwykle wykonujesz ręcznie przez 30-40 minut. Włącz Tryb Plan, utwórz plan i zapisz go w plans/. Wyjdź z Trybu Plan. Ustaw /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Zamknij laptop na godzinę i zajmij się czymś innym. Wróć i sprawdź wynik.

Te trzy kroki to minimum. Buduje się to stopniowo; nie próbuj zrobić wszystkiego jednego wieczoru. Zacznij od CLAUDE.md, po tygodniu dodaj plans/, a po miesiącu spróbuj uruchomić /goal na noc.

Gdy będziesz gotowy, poznaj Ailoot.