# Claude Code Plan Mode: włączanie i 4 fazy pracy > Tryb Plan w Claude Code: czym jest, jak go włączyć za pomocą Shift+Tab, 4 fazy Anthropic, gotowe szablony poleceń oraz polecenie /goal do autonomicznych zadań wykonywanych przez noc. Source: https://ailoot.ai/blog/pl/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/pl/claude-code-plan-mode/ Language: pl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-2a9d5646ef6daf8cd017c7885921d6c769038fb657661cce9cc86f968d23d50f Dodatkowe instrukcje znajdziesz w [dokumentacji Ailoot](https://ailoot.ai/docs/). ## Czym jest Tryb Plan i dlaczego sam w sobie nie wystarcza?
Najważniejsze informacje Tryb Plan w Claude Code to tryb, w którym AI czyta pliki, analizuje kod i proponuje plan zmian, ale niczego nie zapisuje, dopóki go nie zatwierdzisz. Włącza się go, naciskając dwa razy Shift+Tab albo używając flagi `--permission-mode plan`. Przydaje się przy niepewnym podejściu, nieznanym kodzie lub istotnym ryzyku między plikami albo operacyjnym. Jasna literówka o niskim ryzyku zwykle nie wymaga osobnego planowania.
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:

Tryb Plan poleca Claude zbadać temat i zaproponować zmiany bez ich wprowadzania. Claude czyta pliki, uruchamia polecenia powłoki, by zbadać projekt, i zapisuje plan, ale nie edytuje kodu.

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
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](https://ailoot.ai/blog/pl/context-engineering/) — zarządzanie kontekstem przed poleceniem, a nie w jego trakcie. ## Jak włączyć Tryb Plan w Claude Code?
Najważniejsze informacje Istnieją cztery oficjalne sposoby włączenia Trybu Plan. W trakcie sesji naciśnij dwa razy Shift+Tab albo dodaj przed poleceniem prefiks `/plan`. Przy uruchamianiu użyj flagi `claude --permission-mode plan`. Globalnie ustaw pole `defaultMode` w pliku `.claude/settings.json`. Wskaźnik aktywnego trybu to `⏸ plan mode on` u dołu terminala.
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: ```bash 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: ```json { "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?
Najważniejsze informacje W swoich dobrych praktykach Anthropic wymienia kanoniczny przepływ pracy z czterema fazami: Explore (czytanie plików i poznawanie kontekstu), Plan (tworzenie planu zmian bez edycji), Implement (przejście do zwykłego trybu i wdrażanie planu), Commit (utworzenie commita z opisową wiadomością i pull requesta). Każda faza ma własne ograniczenia dotyczące narzędzi.
Wiele poradników opisuje 3 fazy (Explore-Plan-Execute) albo tylko 2 (Plan-Implement). To uproszczenia. W swoim [oficjalnym przewodniku dobrych praktyk](https://www.anthropic.com/engineering/claude-code-best-practices) 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): | Faza | Co robi Claude | Co robisz ty | Tryb | |----|----|----|----| | **Explore** | Czyta `/src/auth` i sprawdza, jak obsługiwane są sesje oraz zmienne środowiskowe | Określasz zakres analizy | Tryb Plan | | **Plan** | Tworzy plan: które pliki zmienić, które nowe pliki utworzyć i jakie są zagrożenia | Czytasz plan, edytujesz go za pomocą Ctrl+G i zatwierdzasz | Tryb Plan | | **Implement** | Wdraża plan, pisze kod przepływu OAuth, testy i obsługę callbacku | Obserwujesz każdą wprowadzaną zmianę | Default lub acceptEdits | | **Commit** | Tworzy commit z opisem i otwiera pull request | Sprawdzasz wiadomość i przeglądasz pull request | Default | 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ć?
Najważniejsze informacje Dobry plan Claude zawiera listę konkretnych plików i zmian do wprowadzenia, uporządkowaną sekwencję kroków, wyraźnie opisane ryzyka i kryteria sukcesu. Zły plan używa ogólników w rodzaju „zaktualizuję moduł uwierzytelniania”, bez szczegółów. Skorzystaj z 7 poniższych oznak, by zdecydować, czy go zatwierdzić. Doprecyzuj plan, przekazując uwagi, albo edytuj go bezpośrednio za pomocą Ctrl+G.
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
Najważniejsze informacje Sam Tryb Plan działa tylko w bieżącej rozmowie. Zamknij okno, a plan zniknie. Folder `plans/YYYY-MM-DD-feature.md` w repozytorium zamienia plan w trwały artefakt: plik z fazami, polami wyboru i statusami, który może podjąć każdy kolejny agent. To przejście od „planu w pamięci” do „planu w kodzie”.
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ść: | Cecha | Tylko Tryb Plan | Tryb Plan + folder `plans/` | |----|----|----| | Trwałość | Tylko w bieżącym czacie | Na zawsze w repozytorium | | Przekazanie innemu agentowi | Niemożliwe | `cat plans/file.md` | | Wersje i historia | Brak | Za pomocą git diff | | Obsługa podagentów | Tylko w bieżącej sesji | Każda faza → własny podagent | | Pola wyboru i statusy | Tylko tekst | Pola Markdown `[ ]` / `[x]` | | Rozmiar planu | Ograniczony rozmiarem okna | Dowolny | 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?
Najważniejsze informacje `/goal` to autonomiczna pętla, o której Anthropic mówi od roku. Polecenie `/goal` pojawiło się w Claude Code v2.1.139 (11 maja 2026). Ustawia warunek ukończenia, a Claude pracuje nad jego spełnieniem bez udziału człowieka. Niewielki model ewaluacyjny sprawdza po każdej turze, czy warunek został spełniony.
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: ```bash /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:

Aby ograniczyć czas działania celu, dodaj do warunku klauzulę określającą liczbę tur albo czas, na przykład „albo zatrzymaj się po 20 turach”.

— Anthropic Docs, https://code.claude.com/docs/en/goal
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?
Najważniejsze informacje Prosty Tryb Plan bez struktury daje przeciętne wyniki. Skuteczny przepływ pracy obejmuje 4 kroki w jednym oknie: ustalenie faktów bez proponowania rozwiązania, opracowanie opcji na podstawie przykładów z internetu, przygotowanie szczegółowego planu uwzględniającego ryzyka 2-3 kroki naprzód oraz wymaganie od Claude samodzielnego sprawdzenia, czy plan zawiera założenia „wyciągnięte z powietrza”. Ta sekwencja blokuje AI pochlebcę.
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?
Najważniejsze informacje Gotowe polecenia oszczędzają 10-15 minut na zadaniu i poprawiają jakość planu. Istnieje pięć uniwersalnych szablonów: do refaktoryzacji modułu, migracji bazy danych, dodawania nowej funkcji, pisania testów oraz diagnozowania złożonego błędu. Każdy opiera się na 4-etapowym cyklu i jest powiązany z folderem `plans/`.
**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ć?
Najważniejsze informacje Użyj Trybu Plan przy niepewnym podejściu, nieznanym kodzie, decyzjach architektonicznych, migracjach lub istotnych skutkach ubocznych. Liczba plików przypomina o zależnościach, nie jest twardą regułą. Mały, zrozumiały diff niskiego ryzyka można wykonać bezpośrednio; jednozdaniowy opis sam nie czyni uwierzytelniania ani migracji bezpiecznymi.
Anthropic pisze o tym wprost w dokumentacji: [Wskazówki dotyczące planowania](https://www.anthropic.com/engineering/claude-code-best-practices) 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: | Zadanie | Tryb | Dlaczego | |----|----|----| | Literówka w README | Default | Jeden plik, jedna zmiana, oczywisty diff | | Zmiana nazwy zmiennej w jednym pliku | Default | Jasny zakres i sprawdzalne odwołania; oceń skutki uboczne | | Dodanie wiersza logu | Default | Jednowierszowa zmiana, która nie wpływa na logikę | | Dodanie nowego przycisku na stronie | Default | Jeśli chodzi o jeden przycisk i wiesz, gdzie go umieścić, plan nie jest potrzebny | | Refaktoryzacja modułu | Tryb Plan | Co najmniej 5 plików, ryzyko skutków ubocznych | | Migracja bazy danych | Tryb Plan + `/goal` | Proces wieloetapowy; potrzebny plan wycofania zmian | | Dodanie uwierzytelniania | Tryb Plan | Dotyczy co najmniej 10 plików; bezpieczeństwo ma kluczowe znaczenie | | Pisanie testów dla modułu | Tryb Plan | Trzeba ustalić, co testować | | Diagnozowanie niejasnego błędu | Tryb Plan + cykl 4 kroków | Bez diagnozy rozwiązania nie trafią w sedno | | Migracja całego frameworka | Tryb Plan + `plans/` + nocny `/goal` | Długie zadanie wymagające faz i autonomicznej pętli | 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?
Najważniejsze informacje Tryb Plan staje się 10 razy skuteczniejszy w połączeniu z odpowiednio skonfigurowanym plikiem [CLAUDE.md](https://ailoot.ai/blog/pl/claude-md-template/) i [podagentami](https://ailoot.ai/blog/pl/claude-code-subagents/). CLAUDE.md określa zasady, według których Claude przygotowuje plan. Podagenci pozwalają rozdzielić fazy planu między agentów pracujących równolegle. Bez tego połączenia Tryb Plan pozostaje narzędziem jednorazowego użytku.
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](https://ailoot.ai/blog/pl/claude-md-template/). **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](https://ailoot.ai/blog/pl/claude-code-subagents/). 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?
Najważniejsze informacje Tryb Plan często zawodzi przez typowe błędy w użyciu, a nie dlatego, że narzędzie jest słabe. Siedem głównych błędów to: trzymanie planu w pamięci zamiast w pliku, umieszczanie wszystkich zadań w jednym czacie, tworzenie planu bez faz, pomijanie dogłębnego researchu, pozwalanie AI pochlebcy proponować rozwiązanie bez diagnozy, pomijanie samodzielnej weryfikacji i używanie niejasnych warunków w `/goal`.
**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?
Najważniejsze informacje Pierwsze doświadczenie z Trybem Plan to dopiero początek. Kolejne kroki: skonfiguruj [CLAUDE.md](https://ailoot.ai/blog/pl/claude-md-template/), jeśli jeszcze go nie masz (bez niego plan wisi w próżni), utwórz w repozytorium folder `plans/` jako roboczą metodologię i wypróbuj `/goal` w jednym autonomicznym zadaniu przed snem. Połączenie wszystkich trzech elementów — Trybu Plan, CLAUDE.md i `plans/` — tworzy działający system.
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](https://ailoot.ai/blog/pl/claude-md-template/). 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.
### Źródła - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal) - [Anthropic Docs - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
Gdy będziesz gotowy, poznaj [Ailoot](https://ailoot.ai/). ## Pytania i odpowiedzi ### Czy mogę pominąć planowanie, znając pliki do zmiany? Nie. Znane nazwy plików nie usuwają niepewności skutków ubocznych i sprawdzeń. Planuj migracje, uwierzytelnianie i skoordynowane zmiany komponentów także przy jasnej liście plików. ### Kiedy osobna faza Plan Mode jest zbędna? Przy małym, zrozumiałym diffie niskiego ryzyka z oczywistym sprawdzeniem, np. lokalnej literówce, bezpośrednia praca jest rozsądna. Planuj przy niejasnym podejściu, nieznanym kodzie lub ryzykach operacyjnych i między plikami. ## Ailoot · Firma i jej portfel projektów Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI. Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach. Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.