Od planu do działającego kodu w Claude Code

Claude Code zamienia zatwierdzony plan w działający kod w pętli wycinków: wprowadza sesję w plan i istniejący kod, dzieli plan na wycinki wielkości jednego commita, implementuje po jednym wycinku za hookami, które lintują każdą edycję i nie pozwalają zakończyć tury przy czerwonych testach, sprawdza dowody wycinka i commituje go przed następnym.

Ta strona jest dla programistów, którzy mają zatwierdzony plan i muszą go dowieźć, oraz dla tech leadów, którzy decydują, przez jakie bramki przechodzi każdy wycinek. Sytuacja: plan dotyka 12 plików w schemacie, serwisie, trasach i UI. Prosisz Claude Code o „zaimplementuj plan”, a po 40 minutach masz przed sobą diff na 900 linii, który ignoruje twój wzorzec obsługi błędów, poprawia test tak, żeby przechodził, i nie da się go sensownie zrecenzować.

Jeśli planu jeszcze nie ma, najpierw go napisz według planowania funkcji w Claude Code. Jeśli to twoja pierwsza funkcja w Claude Code, zacznij od pierwszej funkcji krok po kroku, która prowadzi jedno zgłoszenie od początku do końca. Ta strona opisuje pętlę dla dłuższych implementacji. Pracujesz w innym narzędziu? Wersję wieloplikowej implementacji zaczynającej się od testów w Cursorze opisują przepływy agenta i czatu w Cursorze.

Co dostajesz z pętli od planu do kodu

• Zestaw dwóch hooków, dzięki któremu „testy przechodzą” jest faktem, którego Claude Code nie może pominąć.
• Cztery prompty do skopiowania: brief wzorców, lista wycinków, implementacja wycinka i raport dowodów.
• Regułę, co czytasz w każdym wycinku, a co powierzasz testom i bramkom.
• Procedurę wznawiania, która podejmuje trzydniową implementację bez tłumaczenia wszystkiego od nowa.
• Sposoby wyjścia z sześciu typowych awarii tej pętli.

Jak działa pętla od planu do kodu w Claude Code?

Każdy wycinek przechodzi te same pięć kroków. Plan jest kontraktem, wycinek jednostką pracy, a commit punktem kontrolnym, do którego możesz wrócić.

Krok	Claude Code robi	Ty sprawdzasz	Dowód
Kontekst	Czyta plan i dwa, trzy pliki pokazujące wasze wzorce	Czy brief wzorców zgadza się z tym, jak zespół pisze kod	Krótki brief w rozmowie
Podział	Dzieli plan na wycinki, każdy z listą plików i linią „gotowe, gdy”	Kolejność, rozmiar i czy każde kryterium akceptacji trafia do któregoś wycinka	Lista wycinków zapisana w pliku planu
Implementacja	Pisze jeden wycinek razem z testami	Na razie nic: najpierw działają bramki	Wynik hooków: lint i testy
Weryfikacja	Raportuje wynik testów, git diff --stat i odstępstwa od planu	Nazwy testów, listę plików, interfejsy publiczne	Raport dowodów
Commit	Commituje wycinek z komunikatem nazywającym wycinek	Komunikat i zielony zestaw testów	Jeden commit na wycinek

Układaj wycinki według zależności: typy i schematy, potem warstwa danych, serwisy, trasy, na końcu UI. Każda warstwa kompiluje się wtedy względem czegoś, co już istnieje. Śledzenie zależności i zmiany nazw w całym kodzie opisuje strona o pracy na wielu plikach.

Ustaw bramki przed pierwszym wycinkiem

To bramki pozwalają przestać czytać każdą linię. Większość pracy robią dwa hooki: hook PostToolUse, który formatuje i lintuje każdy edytowany plik, oraz hook Stop, który uruchamia testy i nie pozwala zakończyć tury, dopóki nie przechodzą. Oba skrypty, format-and-lint.sh i tests-before-stop.sh, razem z testami na fixture’ach, znajdziesz na stronie o hookach. Zarejestruj je w projektowym .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/format-and-lint.sh", "args": [], "timeout": 60 }]
      }
    ],
    "Stop": [
      { "hooks": [{ "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/tests-before-stop.sh", "args": [], "timeout": 300 }] }
    ]
  }
}

Hook PostToolUse dostaje zdarzenie jako JSON na stdin i odczytuje ścieżkę edytowanego pliku z .tool_input.file_path; zmiennej $FILE_PATH nie ma. Żeby błąd lintera wrócił do Claude, skrypt wypisuje go na stderr i kończy się kodem 2. Kod wyjścia 1 pokazuje tylko komunikat „hook error”, a praca idzie dalej. Otwórz /hooks w sesji, żeby sprawdzić, czy oba hooki się załadowały.

Nie wkładaj sprawdzania typów do hooka po każdej edycji. tsc --noEmit po każdym pliku kosztuje w dużym projekcie kilka sekund na plik, a w połowie wycinka typy często są celowo rozjechane. Uruchamiaj je w hooku Stop albo w kroku dowodów.

Potem uruchom nazwaną sesję, żeby łatwo do niej wrócić:

# Terminal, w katalogu głównym repozytorium
claude -n org-management

W Claude Code v2.1.283 z kanału latest interaktywne sesje w terminalu startują w trybie auto, więc klasyfikator zatwierdza większość poleceń bez pytania. Dodaj reguły deny lub ask dla wszystkiego, czego punkt kontrolny nie cofnie, na przykład Bash(git push *) i migracji na współdzielonych bazach. Co /rewind przywraca, a czego nie, opisuje strona o wychodzeniu z błędów.

Wprowadź sesję w plan i kod

Kontekst z sesji planowania nie przechodzi do nowej sesji, a plan wymienia pliki, ale nie pokazuje, jak są napisane. Zanim padnie pierwsza edycja, poproś o brief wzorców. Sprawdzisz go w minutę, a potem wskazujesz na niego, gdy kod zaczyna odpływać.

Prompt do skopiowania: brief wzorców przed implementacją

Read docs/plans/org-management.md, then read these files:
- src/services/user.service.ts
- src/routes/user.routes.ts
- src/schemas/user.schema.ts
- tests/services/user.service.test.ts

Do not edit anything. Write a pattern brief of at most 15 bullets:
naming, error handling (which error class, how it maps to HTTP),
validation (where Zod schemas live and where .parse() is called),
transaction handling, logging, and how tests build fixtures.
Quote the file and line for each bullet. If two files disagree on
a pattern, say so and ask me which one wins.

Popraw brief, jeśli jest błędny. Poprawienie jednego punktu teraz kosztuje mniej niż poprawianie tego samego wzorca w ośmiu plikach później. Jeśli brief przeczy twojemu CLAUDE.md, popraw też CLAUDE.md; zobacz system pamięci.

Podziel plan na wycinki wielkości commita

Wycinek to największa zmiana, która sama zostawia cały zestaw testów zielonym i którą ocenisz po jej dowodach. W praktyce to jedna warstwa jednej funkcji, mniej więcej od trzech do sześciu plików. Linia „gotowe, gdy” każdego wycinka musi dać się udowodnić testem albo poleceniem. Najłatwiej o to, gdy plan ma już wykonywalne kryteria akceptacji.

Prompt do skopiowania: podział planu na wycinki

Using the plan and the pattern brief, split the work into slices.
For each slice give:
1. A name that works as a commit subject (under 72 characters)
2. The exact files it creates or modifies
3. Which acceptance criteria from the plan it satisfies
4. "Done when": the test file(s) and command that prove it
5. Anything it depends on from an earlier slice

Rules: every slice must leave the full test suite green. No slice
touches more than 6 files. Order by dependency: types and schemas,
data layer, services, routes, UI. Every acceptance criterion must
appear in exactly one slice. Append the list to
docs/plans/org-management.md under "## Slices" and stop.

Przejrzyj listę wycinków tak, jak przeglądasz opis pull requesta. Szukaj kryterium, którego nie bierze żaden wycinek, wycinka dotykającego plików spoza planu i linii „gotowe, gdy” w stylu „działa poprawnie” zamiast nazwy testu. Dla ryzykownego wycinka, na przykład migracji albo zmiany autoryzacji, uruchom /plan (albo naciskaj Shift+Tab, aż włączy się tryb planowania) i zatwierdź plan plik po pliku dla samego tego wycinka, zanim padnie jakakolwiek edycja.

Implementuj po jednym wycinku

Nazwij wycinek, powtórz jego granice i powiedz, czego Claude nie może ruszać. To granica sprawia, że diff da się zrecenzować.

Prompt do skopiowania: implementacja jednego wycinka

Implement slice 2 from docs/plans/org-management.md
("Add organization service with CRUD operations").

- Follow the pattern brief. Where the brief is silent, copy
  user.service.ts rather than inventing a new pattern.
- Write the tests in tests/services/org.service.test.ts first and
  run them to show they fail, then implement until they pass.
- Touch only the files the slice lists. If you need another file,
  stop and tell me why before editing it.
- Do not edit existing tests or test fixtures. If an existing test
  fails, report it; do not change it.
- Do not start slice 3.

Od v2.1.280 na kanale wydań latest domyślnym modelem jest Claude Opus 5.5, który działa w Claude Code z wysiłkiem medium. Gdy wycinek wciąż wykłada się na tej samej logice, podnieś wysiłek przez /effort high, zanim pomyślisz o innym modelu; przegląd modeli wyjaśnia, kiedy zmiana modelu się opłaca.

Jak zweryfikować wycinek bez czytania każdej linii?

Hook Stop już udowodnił, że testy są zielone. Zostaje sprawdzić, czy zielone są właściwe rzeczy i czy zmiana nie wyszła poza swoje granice. Poproś o dowody w jednej wiadomości i przeczytaj ją zamiast diffu.

Prompt do skopiowania: raport dowodów dla wycinka

Before I commit slice 2, give me an evidence report:
1. The exact test command you ran and its summary line
2. The names of the new tests, grouped by acceptance criterion
3. Output of: git diff --stat
4. Any file changed that the slice did not list, and why
5. Any change to an exported function signature or a type
6. Any deviation from the plan or the pattern brief
7. Run the type checker and paste its last 10 lines
Do not fix anything in this turn. Only report.

Te części przeczytaj sam, bo testy ich nie ocenią:

• Nazwy testów i asercje. Test creates organization, który sprawdza tylko expect(result).toBeDefined(), niczego nie dowodzi. Upewnij się, że każde kryterium akceptacji ma test, który padnie, gdy zachowanie się zepsuje. Zobacz jak chronić wyrocznię testową.
• Listę plików względem wycinka. Nieoczekiwany plik to najtańszy sygnał dryfu.
• Interfejsy publiczne. Eksportowane sygnatury, odpowiedzi API i zmiany schematu przeżyją wycinek, więc czytaj je w całości.

Po drugą opinię bez wydawania własnej uwagi uruchom wbudowany skill /code-review na niezacommitowanym diffie. Recenzuje w świeżym kontekście, więc nie dzieli założeń rozmowy, w której powstał kod. O tym, co przyjąć, nadal decydujesz ty. Programista zatwierdza każdy wycinek na podstawie tych dowodów. Recenzent pull requesta zatwierdza całą zmianę na podstawie zebranych dowodów ze wszystkich wycinków, tak jak opisuje pakiet dowodów.

Commituj każdy wycinek jako punkt kontrolny

Commituj, gdy tylko dowody wycinka są czyste. Commit na wycinek daje git bisect materiał do pracy, a recenzentowi historię, którą da się śledzić. Daje też punkt oparcia, który przetrwa koniec sesji.

The evidence is clean. Commit slice 2 with the slice name as the
subject line and a body listing the acceptance criteria it covers.
Then mark slice 2 as done in docs/plans/org-management.md.

Punkty kontrolne i commity robią co innego. /rewind (albo dwa razy Esc przy pustym polu promptu) przywraca kod i rozmowę do wcześniejszego promptu w tej samej sesji, co pasuje do nieudanej tury w środku wycinka. Punkty kontrolne śledzą tylko narzędzia Claude do edycji plików, a nie pliki zmienione przez polecenia powłoki, na przykład generator kodu, więc jedynym pewnym cofnięciem ukończonego wycinka jest commit.

Uruchamiaj niezależne wycinki równolegle

Wycinki bez wzajemnych zależności, takie jak UI ustawień organizacji i eksport dziennika audytu, mogą iść jednocześnie. Claude Code daje dwie drogi:

• Subagenty działają w twojej sesji, raportują do niej i domyślnie pracują w tle. Używaj ich do pracy, która dzieli drzewo robocze i nie edytuje tych samych plików, na przykład do pisania testów dla wycinka 3, gdy przeglądasz wycinek 2. Zobacz własne subagenty.
• Worktree dają każdej sesji osobny checkout i gałąź. Uruchomisz je przez claude -w org-audit-export. Używaj ich, gdy dwa wycinki edytowałyby te same pliki albo uruchamiały sprzeczne migracje.

Przy zmianie mechanicznej, która rozpada się na wiele identycznych jednostek, na przykład przeniesieniu 20 tras na nowy typ błędu, podział zrobi za ciebie wbudowany skill /batch: rozkłada zmianę na od 5 do 30 jednostek i każdą uruchamia w subagencie w tle, we własnym worktree. W Codeksie ten sam wzorzec „jeden tor, jedno worktree” opisują przepływy wieloagentowe w Codeksie.

Równoległe wycinki przechodzą te same bramki. Hooki w .claude/settings.json są w repozytorium, więc dostaje je każde worktree.

Wznów implementację w nowej sesji

Długa implementacja rozciąga się na kilka sesji, a rozmowa to najmniej pewne miejsce na jej stan. Trzymaj stan w pliku planu i w gicie, żeby nowa sesja odtworzyła go jednym promptem.

Na koniec sesji poproś Claude o zapisanie statusu w planie: ukończone wycinki z hashami commitów, następny wycinek, decyzje podjęte w trakcie implementacji i otwarte pytania. Następnego dnia uruchom claude --resume org-management, co otwiera listę sesji przefiltrowaną po tej nazwie, albo zacznij czystą sesję i osadź ją ponownie:

Prompt do skopiowania: wznowienie implementacji

Read docs/plans/org-management.md, including "## Slices" and the
status notes, and run: git log --oneline -15
Tell me which slices are committed, which slice is next, and any
open question the notes record. Re-read the pattern brief files
before you edit anything. Do not start implementing until I confirm
the next slice.

Gdy kontekst zapełni się w środku wycinka, uruchom /compact Keep the slice list, the pattern brief and the current slice's progress; drop the exploration. Między wycinkami świeża sesja z promptem wznowienia jest zwykle czystsza niż kompaktowanie. Żeby nazwać sesję uruchomioną bez -n, wpisz /rename org-management.

Co się psuje, gdy zamieniasz plan w kod z Claude Code?

Kod działa, ale nie wygląda jak reszta repozytorium. Brief wzorców został pominięty albo jest zbyt ogólny. Wyjście: /rewind do promptu sprzed wycinka, popraw brief o plik i linię z właściwym wzorcem, uruchom prompt wycinka ponownie.

Test został zmieniony, żeby zestaw przechodził. Hook Stop przepuszcza turę, ale raport dowodów pokazuje zmieniony plik w tests/, którego wycinek nie wymieniał. Wyjście: przywróć test przez git restore tests/<plik> i poproś Claude o wyjaśnienie, dlaczego pierwotna asercja pada. Żeby to było niemożliwe, a nie tylko wykrywalne, dodaj na czas wycinków implementacyjnych regułę uprawnień Edit(/tests/**) do ask albo deny. Ukośnik na początku zakotwicza wzorzec w katalogu głównym projektu w ustawieniach projektu; bez niego ścieżka jest dopasowywana względem katalogu, w którym uruchomiono sesję.

Plan okazuje się błędny w środku wycinka. Claude trafia na ograniczenie, którego plan nie przewidział, i zaczyna je obchodzić. Wyjście: „Stop. Describe what the plan did not account for and propose a change to the plan and the slice list. Do not edit code.” Najpierw popraw plik planu, potem kontynuuj. Ciche obejście zamienia się w niespodziankę na code review.

Każdy wycinek jest zielony, ale funkcja nie działa od początku do końca. Wycinki testowano tylko w izolacji. Wyjście: dodaj wycinek, którego jedynym zadaniem jest test integracyjny albo end-to-end głównej ścieżki użytkownika, i uruchom go po wycinku z trasami. Zobacz testowanie z Claude Code.

Hook Stop się zapętla albo spowalnia każdą turę. Testy trwają minuty albo niestabilny test pada losowo. Wyjście: na czas implementacji zawęź hook do zmienianego pakietu lub wzorca testów, a pełny zestaw uruchamiaj w kroku dowodów i w CI. Niestabilny test odizoluj w osobnym commicie, zamiast pozwalać Claude ponawiać, aż przejdzie. Upewnij się, że tests-before-stop.sh kończy się kodem 0, gdy pole stop_hook_active w danych wejściowych ma wartość true, żeby druga porażka oddała ci sterowanie zamiast zapętlić turę.

Wycinek rozrasta się poza swoją listę plików. Wycinek był za duży albo musiał się zmienić współdzielony typ. Wyjście: zatrzymaj się, niczego nie commituj i poproś Claude o podział pozostałej pracy na dwa wycinki. Jeśli zmienił się współdzielony moduł, uruchom pełny zestaw testów przed kontynuacją i zapisz w planie, że ten moduł wymaga pełnego zestawu.

Dokąd dalej po implementacji

Generowanie testów i TDD z Claude Code Zablokuj plik testów, prowadź red-green-refactor i udowodnij, że testy łapią błędy.

Automatyczne code review z Claude Code Kontrole przed commitem, analiza pull requestów i bramki jakości, zanim spojrzy człowiek.

Przepływy z /goal Pozwól Claude Code przejść listę wycinków bez nadzoru, z metą, którą oceni ewaluator.

Debugowanie z poziomu CLI Prześledź z terminala błąd, który wyszedł w trakcie implementacji.