Od PRD przez plan do zadań w Claude Code: sprawdzalna droga od wymagań do kodu

Workflow od PRD do planu w Claude Code zamienia dokument wymagań produktowych w trzy artefakty do przeglądu: ponumerowane kryteria akceptacji, plan na poziomie plików przygotowany w trybie planowania oraz listę zadań, którą Claude realizuje krok po kroku, weryfikując każdy z nich. Tryb planowania blokuje edycję do zatwierdzenia planu, a ustawienie plansDirectory trzyma pliki planów w repozytorium.

Product manager wrzuca na Slacka dwustronicowy PRD systemu powiadomień: podsumowania mailowe, alerty w aplikacji, wypisywanie się z poszczególnych typów. Jeśli wkleisz go do Claude Code z poleceniem „zbuduj to”, dostaniesz 40 zmienionych plików, schemat bazy, którego nie wybrałeś, i żadnej możliwości sprawdzenia, któremu wymaganiu służy która zmiana. Ta strona jest dla programistów, którzy zaczynają pracę z Claude Code i chcą powtarzalnej drogi od PRD do zmergowanego kodu, oraz dla tech leadów, którzy chcą, by plany przechodziły przegląd w pull requestach, zanim ruszy implementacja.

Co wyniesiesz z workflow PRD

• Trzyfazowy schemat pracy (analiza, plan, wykonanie), który uruchomisz dla każdej funkcji z pisemną specyfikacją.
• Trzy prompty do skopiowania: analizę PRD z ponumerowanymi kryteriami akceptacji, plan, w którym każdy krok wskazuje sprawdzenie dowodzące jego wykonania, oraz realizację zadanie po zadaniu z bramką testów.
• Ustawienie projektu, które zapisuje pliki planów w repozytorium, dzięki czemu kolega z zespołu recenzuje plan w pull requeście.
• Tabelę śledzenia wymagań, dzięki której zatwierdzasz funkcję, porównując kryteria akceptacji z przechodzącymi testami, zamiast czytać każdą linię diffa.
• Sposoby wyjścia z sytuacji, w których ten workflow się sypie.

Czego potrzebujesz na start?

• Zainstalowanego i zalogowanego Claude Code oraz pliku CLAUDE.md, który opisuje stack i konwencje projektu. Jeśli go jeszcze nie masz, zacznij od inicjalizacji projektu. Plan może trzymać się tylko tych reguł architektury, które Claude jest w stanie przeczytać.
• PRD jako pliku w repozytorium, na przykład docs/prd/notifications.md. Plik można wskazać, wersjonować i porównywać; wiadomości wklejonej ze Slacka – nie.
• Komendy testów, która kończy się w kilka minut, na przykład npm test. Od niej zależy bramka na każde zadanie w fazie 3.

To wersja na szybki start. Jeśli funkcja zaczyna się od jednozdaniowej prośby bez pisemnej specyfikacji, skorzystaj z wywiadu o wymagania i audytu planu w świeżej sesji, opisanych w planowaniu funkcji w Claude Code.

Jak przygotować Claude Code do pracy z PRD?

1. Trzymaj plany w repozytorium. Domyślnie Claude Code zapisuje pliki planów w ~/.claude/plans/, poza projektem, gdzie nikt inny ich nie zrecenzuje. Dodaj plansDirectory do pliku ustawień projektu .claude/settings.json:

   {
     "plansDirectory": "docs/plans",
     "showClearContextOnPlanAccept": true
   }

   Drugi klucz dodaje do okna zatwierdzania planu opcję wyczyszczenia kontekstu (patrz Faza 2). Ścieżka jest względna wobec katalogu głównego projektu i musi w nim pozostać. Claude Code 2.1.283 odrzuca ścieżkę spoza projektu, zapisuje błąd w logu i wraca do ~/.claude/plans/.

2. Uruchom sesję w trybie planowania. W tym trybie Claude czyta pliki i przegląda kod, ale nie edytuje plików projektu, dopóki nie zatwierdzisz planu. Od wersji 2.1.283 (oba kanały wydań na 2026-10-12) sesje interaktywne startują w trybie auto, więc tryb planowania musisz włączyć sam. Uruchom w terminalu:

   claude --permission-mode plan

   W trwającej sesji wpisz /plan albo naciskaj Shift+Tab, aż w stopce pojawi się plan mode on.

3. Przy dużym PRD podnieś poziom wysiłku (effort) przed planowaniem, na przykład poleceniem /effort high. Zacznij od domyślnego modelu i dostrój poziom wysiłku, zanim zmienisz model; poziomy opisuje strona głębokie rozumowanie w Claude Code.

Faza 1: Jak sprawić, żeby Claude przeanalizował PRD, zanim napisze kod?

Poproś wyłącznie o analizę. Najcenniejszym wynikiem tej fazy jest lista pytań, na które PRD nie odpowiada, bo każde pytanie bez odpowiedzi staje się w kodzie zgadywaniem. Na drugim miejscu jest ponumerowana lista kryteriów akceptacji, bo kolejne fazy odwołują się właśnie do tych numerów.

Prompt do skopiowania: analiza PRD z ponumerowanymi kryteriami akceptacji

Read @docs/prd/notifications.md and the code it touches. Do not propose
an implementation yet.

1. Summarise the feature in five sentences or fewer.
2. Rewrite every requirement as a numbered, testable acceptance criterion
   (AC-1, AC-2, ...) in Given/When/Then form. Mark any criterion you had to
   infer rather than read in the PRD with (inferred).
3. List the questions the PRD does not answer, ordered by how much of the
   design depends on the answer. For each one, give the default you would
   choose and why.
4. List the existing modules, tables, and APIs this feature will touch,
   with file paths you have actually opened.

Odpowiedz na otwarte pytania w czacie, a potem poproś Claude o aktualizację kryteriów. Każde kryterium oznaczone (inferred) odeślij do product managera: to rozmowa, którą PRD powinien był wymusić, a teraz zajmie minuty zamiast późniejszego przepisywania. Szerzej o zamianie kryteriów w czerwone testy piszemy w artykule wykonywalne kryteria akceptacji.

Faza 2: Jak zamienić analizę w plan, który da się zrecenzować?

Plan nadający się do przeglądu wymienia pliki, porządkuje kroki według zależności i mówi, jak sprawdzić każdy z nich. Plan bez sprawdzenia przy każdym kroku da się ocenić tylko przez czytanie powstałego kodu, a właśnie tej pracy chcesz uniknąć.

Prompt do skopiowania: plan, w którym każdy krok wskazuje dowód

Using the agreed acceptance criteria, write the implementation plan.

For each numbered step, give:
- the files to create or change (existing paths must be ones you opened)
- what changes, in two or three lines
- which acceptance criteria (AC-n) the step satisfies
- the steps it depends on
- the exact command that proves the step is done, such as a named test file
  run with `npm test -- <file>`, a type check, or a migration dry run
- size: small, medium or large; split anything large

End with a table mapping every AC to the step and the test that covers it.
Any AC without a test is a gap: flag it rather than hiding it.

Claude przedstawia plan w oknie zatwierdzenia. Oceń go przez pryzmat trzech pytań: czy każde kryterium akceptacji ma przypisany test, czy któryś krok dotyka pliku, którego Claude nie otworzył, i czy któryś krok jest na tyle duży, że ukrywa decyzję projektową. Jeśli plan nie przechodzi któregoś z tych sprawdzeń, wpisz uwagi, a Claude poprawi plan, nie wychodząc z trybu planowania.

Przy zatwierdzaniu okno w Claude Code 2.1.283 domyślnie daje dwa sposoby kontynuacji: zachowanie kontekstu i dalszą pracę w trybie auto (albo z automatyczną akceptacją edycji, gdy tryb auto jest niedostępny) lub zachowanie kontekstu i ręczne zatwierdzanie każdej edycji. Przy pierwszych kilku przebiegach wybierz ręczne zatwierdzanie, żeby zobaczyć, co Claude robi z planem. Ponieważ krok 1 ustawił showClearContextOnPlanAccept, okno oferuje też opcję wyczyszczenia kontekstu, która pokazuje, jaka część okna kontekstu jest zajęta (domyślnie false, sprawdzone w Claude Code 2.1.283). Wyczyszczenie kontekstu przydaje się po długiej analizie, bo wykonanie startuje wtedy od pliku planu, a nie od zapełnionego okna kontekstu, a odczyt zajętości od razu pokazuje, czy czyszczenie się opłaca.

Na potrzeby przeglądu zespołowego zacommituj plik planu z docs/plans/ na gałęzi funkcji i otwórz szkic pull requesta przed implementacją. Recenzent komentuje podejście i tabelę kryteriów akceptacji, a nie kod, którego jeszcze nie ma.

Faza 3: Jak wykonać plan jako śledzoną listę zadań?

Claude Code prowadzi listę zadań przy pracy wieloetapowej. Naciśnij Ctrl+T, żeby ją pokazać lub ukryć, gdy Claude pracuje. Poproś o jedno zadanie na każdy krok planu i uzależnij oznaczenie zadania jako ukończonego od komendy dowodzącej jego wykonania.

Prompt do skopiowania: realizacja zadanie po zadaniu z bramką testów

Execute the approved plan in docs/plans/. Create one task per plan step,
in dependency order.

For each task, in order:
a) Write or update the test named in the plan first and run it; it should fail.
b) Implement the step.
c) Run the step's proof command, then the type check and the linter.
d) Mark the task complete only when all three pass. If a check fails twice,
   stop and tell me what failed instead of weakening the test.
e) Commit with a message that names the step number and the ACs it covers.

Stop after you complete plan step 3 so I can check direction before you continue.

Sformułowanie „instead of weakening the test” jest kluczowe. Bez niego agent, który chce domknąć zadanie, czasem poprawia asercję zamiast kodu. Pauza po kroku 3 planu daje tani punkt kontrolny: schemat i warstwa serwisowa już istnieją, ale nic jeszcze od nich nie zależy.

Jak zweryfikować funkcję bez czytania każdej linii?

Zatwierdzenie opiera się na dowodach, które sprawdzisz w kilka minut, a nie na czytaniu diffa. Poproś Claude, żeby na koniec je przygotował:

Prompt do skopiowania: raport śledzenia kryteriów akceptacji

Produce a traceability report for this feature. For every acceptance
criterion AC-n: the test file and test name that covers it, whether it
passes right now (run the tests, do not assume), and any AC that is only
partly covered. Then list every file changed that no plan step mentions.

Sprawdzenie	Co dowodzi	Kto zatwierdza
Kryteria akceptacji i plan w szkicu PR	Budujemy właściwą rzecz, w sensownej kolejności	Product manager i tech lead, przed implementacją
Każde kryterium ma przechodzący test	Każde wymaganie działa zgodnie z ustaleniami	Programista, na podstawie raportu śledzenia
Sprawdzenie typów, linter i pełny zestaw testów w CI	Nic innego się nie zepsuło	CI, przy każdym pushu
Pliki zmienione poza planem	Zakres się nie rozlał	Programista; każdy plik jest wyjaśniony albo cofnięty
/code-review w świeżej sesji	Drugie przejście w poszukiwaniu błędów, których testy nie wyrażają	Programista czyta wnioski, a nie cały diff

Kod nadal czytasz tam, gdzie ryzyko jest skupione: w migracjach, uwierzytelnianiu i wszystkim, co wysyła maile do prawdziwych użytkowników. W pozostałych miejscach nieudane sprawdzenie pokazuje, gdzie patrzeć. Żeby wymusić bramkę bez polegania na prompcie, uruchamiaj komendę testów z hooka; zobacz automatyzację hookami.

Jak ten workflow wygląda na przykładowej funkcji?

W przykładzie dla PRD powiadomień w aplikacji Next.js z Drizzle ORM i Resend faza 1 daje 11 kryteriów akceptacji i sześć otwartych pytań. Pytanie, które zmienia projekt, brzmi: „Czy codzienne podsumowanie uwzględnia strefę czasową użytkownika?” PRD tego nie precyzuje, a odpowiedź przesądza, czy zadanie wysyłające podsumowania działa raz na dobę, czy co godzinę.

Zatwierdzony plan ma osiem kroków:

1. Schemat: tabele notifications i notification_preferences z migracją. Dowód: migrację da się lokalnie zastosować i wycofać.
2. API preferencji: GET i PUT /api/notifications/preferences z walidacją danych wejściowych. Dowód: testy tras dla AC-1 do AC-3.
3. Serwis powiadomień: tworzenie, deduplikacja i odczyt preferencji. Dowód: testy jednostkowe dla AC-4 do AC-6.
4. Szablony maili dla wysyłki natychmiastowej i podsumowań. Dowód: testy snapshotowe dla AC-7.
5. Zadanie podsumowań uruchamiane co godzinę i filtrowane po strefie czasowej. Dowód: test z podstawionym zegarem dla AC-8 i AC-9.
6. Interfejs historii powiadomień. Dowód: test komponentu dla AC-10.
7. Obsługa wypisania z danego typu przez podpisany link. Dowód: testy dla AC-11, w tym dla zmodyfikowanego linku.
8. Raport śledzenia i /code-review.

Podczas przeglądu tech lead przenosi krok 5 do drugiego pull requesta, żeby powiadomienia natychmiastowe mogły wyjść wcześniej. To zmiana jednej linii planu, która nic nie kosztuje, bo kod jeszcze nie istnieje.

Jak zmienić plan, gdy praca już ruszyła?

Plany się zmieniają. Powiedz Claude, co się zmieniło, i poproś o aktualizację pliku planu i listy zadań jednocześnie, żeby się nie rozjechały:

Move step 5 (digest job) out of this plan into a follow-up. Update the plan
file, the AC table, and the task list. List which ACs are now uncovered.

Step 3 is too big. Split it into one step per notification type (comments,
mentions, assignments), each with its own test. Update the plan file first.

Kiedy workflow od PRD do planu się sypie

Claude zaczyna pisać kod już podczas analizy. Nie jesteś w trybie planowania albo sesja wyszła z niego po zatwierdzeniu. Sprawdź, czy stopka pokazuje plan mode on, wróć do trybu poleceniem /plan, a następną sesję uruchom przez claude --permission-mode plan.

Plan wymienia pliki, które nie istnieją. Claude zgadł strukturę, zamiast ją przeczytać. Odrzuć plan z uwagą: „Open every file you listed and confirm its path. Remove or correct any path you have not opened.” Wiersz „paths you have actually opened” w promptach zapobiega większości takich przypadków.

Plan jest zbyt ogólny, żeby go ocenić. Kroki w stylu „zaimplementuj warstwę serwisową” ukrywają decyzje. Poproś o sygnatury funkcji i test dowodzący każdego kroku: „For step 3, list the functions you will add, their signatures, and the test cases for each.”

Pliku planu nie ma w repozytorium. Brakuje plansDirectory, klucz trafił do niewłaściwego pliku ustawień albo wskazuje poza katalog projektu, więc Claude Code wrócił do ~/.claude/plans/. Umieść klucz w .claude/settings.json ze ścieżką względną wobec katalogu głównego i uruchom sesję ponownie.

Claude pracuje w złej kolejności albo pomija zadanie z nieprzechodzącym testem. Naciśnij Ctrl+T, żeby zobaczyć listę zadań, i skoryguj kurs: „Stop. Step 4 depends on step 2, which is not complete. Finish step 2 and show me its test run.”

W połowie dużego planu kończy się kontekst. Długa analiza razem z wykonaniem zapełnia okno. Ponieważ plan i kryteria akceptacji są plikami, uruchom świeżą sesję i napisz: „Read the plan in docs/plans/ and git log, then continue from the first step without a commit.” Cofanie sesji, która poszła w złą stronę, opisuje strona odzyskiwanie po błędach.

Plan ignoruje twoją architekturę. Reguły nie są zapisane tam, gdzie Claude je czyta. Dodaj je do CLAUDE.md, na przykład „all database access goes through src/db/repositories”, a potem poproś Claude o ponowne zaplanowanie. Gdzie umieścić który rodzaj reguły, wyjaśnia system pamięci.

Dokąd dalej z planowaniem opartym na PRD

Ten sam schemat pracy działa w innych narzędziach: użytkownicy Cursora znajdą go w workflow PRD w Cursorze, a użytkownicy Codexa zaczną od pierwszego zadania w Codexie. Metodę stojącą za tymi artefaktami opisują łańcuch artefaktów i spec-driven development.

Planowanie funkcji w Claude Code Wywiad o wymagania, kryteria akceptacji i audyt planu w świeżej sesji

Głębokie rozumowanie Poziomy wysiłku (effort) dla trudnych decyzji projektowych w planie

Workflow deweloperski Codzienna pętla pracy po zatwierdzeniu planu

Wykonywalne kryteria akceptacji Każde kryterium jako czerwony test przed implementacją