Metodologia od PRD przez plan do listy zadań

Masz zadanie w Jira, które mówi “Dodaj powiadomienia użytkownika”. Twój PM chce to na piątek. Otwierasz Cursor, Claude Code lub Codex, wklejasz opis zadania i naciskasz enter. AI generuje 400 linii kodu, który wygląda wiarygodnie, ale pomija połowę wymagań, wymyśla schemat tabeli powiadomień kolidujący z twoją istniejącą bazą danych i całkowicie ignoruje konwencje API twojego zespołu.

Problem nie leży w AI. Problem polega na tym, że pominąłeś fazę planowania i poprosiłeś system probabilistyczny o podejmowanie decyzji architektonicznych, do których nie jest uprawniony.

Czego się nauczysz

Powtarzalny trzyfazowy przepływ pracy (PRD, Plan, Lista zadań), który działa w Cursor, Claude Code i Codex
Gotowe do skopiowania prompty na każdą fazę, których możesz użyć przy następnej funkcjonalności
Strategia utrzymywania AI skupionego na implementacji, podczas gdy ty odpowiadasz za architekturę
Techniki zapisywania planu jako artefaktu wielokrotnego użytku, który przetrwa resety kontekstu

Trzy fazy

Metodologia od PRD przez plan do listy zadań oddziela myślenie od działania. Inwestujesz 15-20 minut w ustrukturyzowane planowanie, aby zaoszczędzić godziny debugowania i przeróbek.

Faza 1: Wchłonięcie PRD

Każda funkcjonalność zaczyna się od wymagania. Może to być formalny dokument wymagań produktu (PRD), historia użytkownika, wiadomość na Slack od twojego PM lub zgłoszenie błędu. Bez względu na formę, musisz wprowadzić to do narzędzia AI jako fundamentalny kontekst.

Kluczowa zasada: AI czyta wymaganie, ale ty walidujesz jego zrozumienie, zanim napisze choćby jedną linię kodu.

Umieść PRD w repozytorium (np. docs/notifications-prd.md). Otwórz tryb Agent i odwołaj się do niego bezpośrednio:

Read @docs/notifications-prd.md and summarize the key requirements.
List any ambiguities or missing details I should clarify before we plan.
Do not write any code yet.

Agent Cursor przeczyta plik, porówna go z twoją bazą kodu za pomocą wyszukiwania semantycznego i zasygnalizuje pytania, o których możesz nie pomyśleć. Użyj @codebase, żeby pozwolić mu przeskanować istniejące wzorce.

Trzymaj PRD w repozytorium lub przekieruj go bezpośrednio. Użyj Plan Mode (Shift+Tab do przełączania), żeby zapobiec jakimkolwiek modyfikacjom plików:

Read docs/notifications-prd.md. Summarize the requirements and
identify anything ambiguous or underspecified. Cross-reference
against the existing codebase to find related code.
Do not make any changes yet.

Claude Code przeszuka bazę kodu, przeczyta odpowiednie pliki i złoży raport. Plan Mode zapewnia, że nic nie zostanie zmodyfikowane podczas tej fazy eksploracji.

Odwołaj się do PRD w swoim prompcie. Codex może pracować z poziomu aplikacji, CLI, IDE lub chmury:

Read docs/notifications-prd.md and summarize the requirements.
Identify any ambiguities and list what existing code is related.
Do not make any code changes.

W aplikacji Codex możesz również dołączyć obrazy makiet lub zrzuty ekranów obok PRD jako dodatkowy kontekst. Codex przeanalizuje zarówno tekst, jak i materiały wizualne, zanim zaproponuje plan.

Read the requirements in @docs/[feature]-prd.md. Before we start planning:

1. Summarize the core requirements in your own words
2. List any ambiguities or gaps in the requirements
3. Identify existing code, patterns, and database tables that are relevant
4. Flag any potential conflicts with the current architecture

Do not write any implementation code. We are in the planning phase.

Faza 2: Wspólne planowanie

Po zrozumieniu wymagań wspólnie tworzycie plan implementacji. To miejsce, gdzie twoja wiedza architektoniczna ma największe znaczenie. AI proponuje, ty oceniasz i razem udoskonalacie, aż plan będzie solidny.

Pozostań w trybie Agent. Poproś o ustrukturyzowany plan i iteruj nad nim:

Based on the PRD and your analysis of the codebase, create a
high-level implementation plan covering:

1. Database schema changes (migrations)
2. Backend API endpoints (following our existing patterns in src/api/)
3. Frontend components (following our component patterns)
4. Integration points with existing notification systems

Do not write code. Output the plan as a markdown document.

Przejrzyj plan dokładnie. Kwestionuj decyzje architektoniczne:

The plan proposes a new notifications table, but we already have
an events table that could be extended. What are the trade-offs
of each approach? Which aligns better with our existing patterns?

Kontynuuj w Plan Mode. Poproś Claude o stworzenie planu i naciśnij Ctrl+G, żeby edytować plan bezpośrednio w edytorze tekstu:

Create a detailed implementation plan for the notifications feature.
Cover database changes, API endpoints, frontend components, and
integration points. Follow the patterns you found in the codebase.

Output as a structured markdown plan I can review.

Użyj techniki wywiadu dla złożonych funkcjonalności:

Before writing the plan, interview me about the requirements.
Ask about edge cases, performance requirements, and constraints
I might not have mentioned. Use the AskUserQuestion tool.

Codex doskonale radzi sobie z planowaniem na różnych powierzchniach. Użyj aplikacji do złożonego planowania, ponieważ oferuje najlepsze doświadczenie przeglądania:

Create an implementation plan for the notifications feature based
on the PRD. Analyze the existing codebase for patterns to follow.
Cover: database, API, frontend, and integration points.

Output the plan as docs/notifications-plan.md so the team can review.

Dzięki integracji Codex z GitHub możesz poprosić go o utworzenie wersji roboczej PR zawierającej tylko dokument planu do przeglądania przez zespół, zanim rozpocznie się jakakolwiek implementacja.

Create an implementation plan for this feature. Follow these constraints:

1. Reuse existing patterns from the codebase (show me which files you're using as references)
2. Minimize new dependencies -- prefer what's already in package.json
3. Break the work into layers: database, backend, frontend
4. For each layer, describe WHAT changes and WHY
5. Call out any decisions where there are meaningful trade-offs

Save the plan to docs/[feature]-plan.md. Do not implement anything yet.

Faza 3: Wygeneruj listę zadań

Plan staje się listą kontrolną. Każdy element powinien być na tyle mały, aby można go było zaimplementować i zweryfikować w pojedynczej interakcji z AI. To właśnie sprawia, że metodologia jest niezawodna: zamiast prosić AI o zbudowanie całej funkcjonalności, dajesz mu jedno skupione zadanie na raz.

Convert the implementation plan into a detailed, ordered todo list.
Each task should:
- Be implementable in a single focused session
- Have clear acceptance criteria
- Include the specific files to modify
- Be ordered so each task builds on the previous one

Save this as docs/notifications-todo.md

Cursor natywnie śledzi elementy listy zadań. Możesz odwoływać się do pliku listy zadań przez całą implementację za pomocą @docs/notifications-todo.md i prosić Cursor o oznaczanie elementów jako ukończone w miarę postępu.

Wyjdź z Plan Mode (Shift+Tab), aby pozwolić Claude utworzyć plik:

Convert our plan into an actionable todo list. Requirements:
- Each task is a single, verifiable unit of work
- Tasks include the files that need modification
- Tasks are ordered by dependency (database first, then API, then UI)
- Include test tasks after each implementation task

Save to docs/notifications-todo.md

Narzędzie TodoWrite w Claude Code może zarządzać tymi elementami między sesjami. Użyj --continue, żeby wrócić do miejsca, w którym skończyłeś.

Convert the plan into an ordered todo checklist in
docs/notifications-todo.md. Each item should be:
- A single implementable task
- Include files to create or modify
- Include verification steps (tests to run, behavior to check)
- Ordered by dependency

Format as markdown checkboxes so I can track progress.

Codex może następnie systematycznie pracować przez listę. W aplikacji każdy element listy zadań może stać się własnym wątkiem, utrzymując kontekst skupiony i czysty.

Read @docs/[feature]-todo.md. Implement the next unchecked task.

After implementing:
1. Run the relevant tests
2. Mark the task as complete in the todo file
3. Show me what you changed and why

Stop after completing this single task so I can review before continuing.

Pętla wykonawcza

Z listą zadań w ręku implementacja staje się przewidywalną pętlą:

Wybierz następne nieodznaczone zadanie z listy
Daj AI zadanie z planem jako kontekstem referencyjnym
Pozwól AI je zaimplementować
Zweryfikuj (uruchom testy, przejrzyj diff)
Commituj zmianę
Powtórz

Każda iteracja jest mała, możliwa do przejrzenia i odwracalna. Jeśli AI zejdzie z kursu przy zadaniu 7, tracisz tylko pracę z tego jednego zadania, a nie całej funkcjonalności.

Kiedy to nie działa

PRD jest zbyt ogólnikowy. Jeśli wymaganie brzmi “ulepsz powiadomienia”, żadna metodologia cię nie uratuje. Poproś PM o doprecyzowanie lub sam napisz bardziej szczegółowe PRD. AI może pomóc: poproś go o wygenerowanie szablonu PRD i wypełnienie tego, co wiesz.

Plan jest zbyt ambitny. Jeśli twój plan ma 40+ elementów listy zadań, funkcjonalność jest za duża na jeden cykl. Podziel ją na kamienie milowe, z których każdy dostarcza widoczną dla użytkownika wartość. Dostarcz kamień milowy 1, zanim zaczniesz planować kamień milowy 2.

AI odchodzi od planu. Ograniczenia okna kontekstowego oznaczają, że AI może “zapomniało” o wcześniejszym planowaniu w długich sesjach. Odwołuj się jawnie do pliku planu w każdym prompcie (@docs/notifications-plan.md). W Claude Code użyj /clear między zadaniami i ponownie odwołaj się do planu. W Codex używaj oddzielnych wątków na każde zadanie.

Pomijasz fazę planowania “tylko tym razem”. Każdy programista, który próbował przeskoczyć prosto do implementacji, nauczył się tej samej lekcji: czas, który oszczędzasz pomijając plan, spędzasz potrojnie na debugowaniu. 15-minutowa inwestycja w planowanie zwraca się przy każdej funkcjonalności większej niż zmiana w jednym pliku.

Co dalej

Programowanie sterowane testami Dodaj TDD do przepływu PRD-Plan-Todo dla wbudowanej weryfikacji na każdym kroku.

Człowiek w pętli Dowiedz się, kiedy interweniować podczas wykonywania, a kiedy pozwolić AI działać.

Okna kontekstowe Zrozum, jak limity tokenów wpływają na długie sesje planowania i implementacji.