Metodologia PRD→Plan→Todo

Metodologia PRD→Plan→Todo to systematyczne podejście do rozwoju wspomaganego przez AI, które przekształca wysokopoziomowe wymagania w działający kod przez trzy odrębne fazy. Ten przepływ pracy stał się złotym standardem dla zespołów używających Claude Code i Cursor.

Trzy filary

1. PRD (dokument wymagań produktu): co trzeba zbudować
2. Plan: jak to zbudować (podejście techniczne)
3. Todo: konkretne zadania implementacyjne

Dlaczego ta metodologia działa

Tradycyjny rozwój często przeskakuje bezpośrednio z wymagań do kodu, prowadząc do:

• Niepasujących implementacji
• Zapomnianych przypadków brzegowych
• Długu technicznego z powodu słabego planowania
• Trudnych przeglądów kodu

Podejście PRD→Plan→Todo zapewnia:

• Jasne dopasowanie między potrzebami biznesowymi a implementacją techniczną
• Kompleksowe pokrycie wszystkich wymagań
• Systematyczną strukturę, którą AI może konsekwentnie się kierować
• Wbudowaną dokumentację dla przyszłego utrzymania

Faza 1: PRD (dokument wymagań produktu)

PRD definiuje co należy zbudować z perspektywy biznesowej.

Tworzenie skutecznych PRD

Struktura

# Funkcja: system uwierzytelnienia użytkownika

## Przegląd
Krótki opis funkcji i jej wartości biznesowej

## Historie użytkowników
Jako [typ użytkownika], chcę [akcja], aby [korzyść]

## Wymagania funkcjonalne
1. Użytkownicy mogą się rejestrować email/hasło
2. Wymagana weryfikacja emaila
3. Funkcjonalność resetowania hasła
4. Opcja "zapamiętaj mnie"

## Wymagania niefunkcjonalne
- Czas odpowiedzi < 200ms
- Obsługa 10k równoczesnych użytkowników
- Zgodność z GDPR
- Dostępność WCAG 2.1 AA

## Kryteria akceptacji
- ☐ Użytkownik może się pomyślnie zarejestrować
- ☐ Nieprawidłowe emaile są odrzucane
- ☐ Hasła spełniają wymagania bezpieczeństwa
- ☐ Sesja utrzymuje się z "zapamiętaj mnie"

## Poza zakresem
- Logowanie społecznościowe (Faza 2)
- Uwierzytelnienie dwuskładnikowe (Faza 2)

Prompt AI

Wskazówka

Prompt do skopiowania, generujący PRD:

Generate a PRD for a passwordless email-and-magic-link login feature. Include: an overview with business value, user stories for end users and admins, a numbered list of functional requirements, non-functional requirements (performance, security, GDPR compliance), testable acceptance criteria, an explicit out-of-scope list, UI/UX requirements, and the integration points with our existing user service. Ask me about anything ambiguous before finalizing.

Podmień opis funkcji na własny, ale trzymaj go konkretnym. Mgliste “generate a PRD for auth” daje mglisty PRD.

Najlepsze praktyki

• Bądź konkretny: “Użytkownik widzi komunikat błędu” → “Użytkownik widzi komunikat ‘Email już istnieje’ na czerwono pod polem email”
• Dołączaj przykłady: Pokaż przykładowe dane wejściowe/wyjściowe
• Zdefiniuj przypadki brzegowe: Co się dzieje, gdy coś pójdzie nie tak?
• Ustaw mierzalne kryteria: Użyj liczb dla wymagań wydajności
• Rozważ wszystkich użytkowników: Uwzględnij adminów, zwykłych użytkowników, gości
• Kontrola wersji: Śledź zmiany PRD w czasie

Przykład rzeczywistego PRD

Funkcja kasy e-commerce

# PRD: funkcja szybkiej kasy

## Przegląd
Zaimplementuj kasę jednym kliknięciem dla powracających klientów, aby zmniejszyć porzucanie koszyka o 25%

## Historie użytkowników
1. Jako powracający klient, chcę dokończyć zakup jednym kliknięciem
2. Jako nowy klient, chcę mieć opcję zapisania moich danych na przyszłość
3. Jako admin, chcę śledzić użycie szybkiej kasy

## Wymagania funkcjonalne
1. Przechowuj zaszyfrowane metody płatności (zgodnie z PCI)
2. Wypełnij adres wysyłki z ostatniego zamówienia
3. Pokaż podsumowanie zamówienia przed potwierdzeniem
4. Wyślij paragon email natychmiast
5. Aktualizuj zapasy w czasie rzeczywistym

## Wymagania wydajności
- Dokończenie kasy < 3 sekundy
- Obsługa 1000 równoczesnych kas
- 99.9% dostępności w godzinach biznesowych

Faza 2: plan techniczny

Plan przekłada wymagania biznesowe na architekturę techniczną i podejście.

Tworzenie kompleksowych planów

Zacznij od przekształcenia PRD w plan, a następnie zejdź do komponentów i ryzyk.

Wskazówka

Prompt do skopiowania, generujący plan techniczny:

Based on this PRD, create a technical plan. Include: a high-level architecture overview, technology choices with a one-line justification each, the data model design, the API endpoints needed, security considerations, integration points with existing systems, and a deployment strategy. Do not write implementation code yet, this is a plan for me to review.

Następnie naciśnij AI, aby rozłożyło architekturę na części i ujawniło ryzyka:

Break down the architecture into:
- Frontend components/pages needed
- Backend services/modules
- Database schema changes
- External service integrations
- Infrastructure requirements

Then list the technical risks and how we mitigate each one
(performance bottlenecks, security vulnerabilities, scalability
limits, third-party dependencies).

Szablon planu

Plan backend

# Plan techniczny: uwierzytelnienie użytkownika

## Przegląd architektury
- Uwierzytelnienie bezstanowe oparte na JWT
- PostgreSQL dla danych użytkownika
- Redis do zarządzania sesjami
- Usługa email do powiadomień

## Projekt API
POST /api/auth/register
POST /api/auth/login
POST /api/auth/logout
POST /api/auth/refresh
POST /api/auth/reset-password

## Schemat bazy danych
users:
- id (uuid, klucz główny)
- email (unikalny, indeksowany)
- password_hash
- email_verified (boolean)
- created_at, updated_at

sessions:
- token (klucz główny)
- user_id (klucz obcy)
- expires_at
- ip_address

## Środki bezpieczeństwa
- Bcrypt do hashowania haseł (12 rund)
- Ograniczanie częstotliwości na endpointach auth
- Prawidłowo skonfigurowany CORS
- Walidacja wejść na wszystkich polach

Plan frontend

# Plan techniczny frontend

## Architektura komponentów
- AuthProvider (kontekst dla stanu auth)
- Komponent LoginForm
- Komponent RegisterForm
- PasswordResetFlow
- AuthGuard HOC dla chronionego routingu

## Zarządzanie stanem
- Hook useAuth do operacji auth
- Local storage do trwałości tokenów
- Session storage do tymczasowych danych

## Przepływ UI/UX
1. Formularze auth oparte na modalu
2. Walidacja w czasie rzeczywistym
3. Stany ładowania podczas wywołań API
4. Powiadomienia sukcesu/błędu
5. Przekierowanie po logowaniu

## Wydajność
- Lazy load komponentów auth
- Prefetch sprawdzenia auth przy ładowaniu aplikacji
- Optymistyczne aktualizacje UI

Faza 3: lista todo (zadania implementacyjne)

Lista todo dzieli plan na konkretne, wykonalne zadania, które można zaimplementować.

Generowanie skutecznych todo

Wskazówka

Prompt do skopiowania, rozbijający plan na todo:

Convert this technical plan into a detailed todo list. Each task must be completable in 1 to 4 hours, grouped by component or feature area, with explicit dependencies, a P0/P1/P2 priority, and a clear acceptance criterion. Include a testing task for every component and a documentation task at the end. Output it as a Markdown checklist.

Przykład listy todo

Format strukturalny

# Todo implementacji: uwierzytelnienie użytkownika

## Konfiguracja bazy danych (P0)
- ☐ Stwórz migracje bazy danych dla tabeli users
- ☐ Stwórz migracje bazy danych dla tabeli sessions
- ☐ Dodaj indeksy dla wyszukiwania email i token
- ☐ Zasiej bazę danych testowymi użytkownikami

## API backend (P0)
- ☐ Zaimplementuj narzędzie hashowania haseł
- ☐ Stwórz endpoint POST /api/auth/register
  - Walidacja wejść
  - Sprawdzenie unikalności email
  - Wyślij email weryfikacyjny
- ☐ Stwórz endpoint POST /api/auth/login
  - Waliduj dane uwierzytelnienia
  - Wygeneruj token JWT
  - Stwórz rekord sesji
- ☐ Dodaj middleware ograniczania częstotliwości
- ☐ Napisz testy integracji API

## Komponenty frontend (P1)
- ☐ Stwórz AuthContext i Provider
- ☐ Zaimplementuj hook useAuth
- ☐ Zbuduj komponent LoginForm
  - Walidacja formularza
  - Obsługa błędów
  - Stany ładowania
- ☐ Zbuduj komponent RegisterForm
- ☐ Dodaj AuthGuard HOC
- ☐ Napisz testy komponentów

## Integracja (P1)
- ☐ Połącz frontend z API backend
- ☐ Zaimplementuj logikę odświeżania tokenów
- ☐ Dodaj interceptory błędów
- ☐ Przetestuj pełny przepływ auth

## Dokumentacja (P2)
- ☐ Udokumentuj endpointy API
- ☐ Stwórz diagram przepływu auth
- ☐ Napisz przewodnik wdrożenia

Format przyjazny AI

## Todo: zaimplementuj rejestrację użytkownika

**Zadanie**: Stwórz endpoint rejestracji użytkownika
**Kryteria akceptacji**:
- Waliduje format email
- Sprawdza unikalność email
- Hashuje hasło z bcrypt
- Wysyła email weryfikacyjny
- Zwraca odpowiednie błędy

**Zależności**: migracje bazy danych ukończone
**Priorytet**: P0
**Szacowany czas**: 2 godziny

**Notatki implementacyjne**:
- Użyj Joi do walidacji
- Zwróć 409 dla duplikatu email
- Loguj próby rejestracji

Wykonywanie z pomocą AI

Przepływ od PRD do planu do todo jest w duchu identyczny we wszystkich trzech narzędziach: podajesz PRD, planujesz w trybie tylko do odczytu, a potem implementujesz po jednym todo na raz. Różni się to, jak każde narzędzie wchłania kontekst i bramkuje swoje edycje.

Cursor

Odwołaj się do PRD przez @docs/auth-prd.md, przełącz agenta w tryb Plan, aby przejrzeć podejście, a następnie zaakceptuj, by zaimplementować. Twoje konwencje żyją w .cursor/rules (nowoczesny następca .cursorrules).

Read @docs/auth-prd.md. In Plan mode, propose the technical
plan and the file changes for the database schema and the
register/login endpoints. Follow the conventions in
.cursor/rules. I'll review the plan before you apply edits.

Następnie przepracuj listę todo skoncentrowanymi działaniami uzupełniającymi, akceptując każdy diff przed przejściem dalej.

Claude Code

Uruchom claude w katalogu projektu i podaj mu PRD. Użyj /plan, aby planował w trybie tylko do odczytu, zanim dotknie plików; Claude śledzi powstałe todo w ramach sesji i przerabia je po jednym na raz.

Read the requirements in @docs/auth-prd.md, then enter plan
mode and produce a technical plan. Once I approve it, convert
it into a todo list, track those todos, and implement them one
at a time, pausing after each for review.

Aby uzyskać głębsze rozumowanie podczas planowania, podnieś poziom wysiłku w /model, zamiast pisać “think harder” (słowa kluczowe rozumowania nie przydzielają już budżetu).

Codex

Umieść trwały kontekst projektu w AGENTS.md w katalogu głównym repozytorium, aby każda sesja ładowała Twoje konwencje. Uruchom codex, przełącz /plan-mode (lub zacznij od codex --sandbox read-only), aby planować bez edycji, i uruchom /review na diffie, zanim cokolwiek umieścisz w staging.

Read @docs/auth-prd.md and the conventions in AGENTS.md. In
plan mode, produce the technical plan and a dependency-ordered
todo list. After I approve, implement the first task only, then
stop so I can /review the diff.

Strumieniowany plan pokazuje każdy krok jako oczekujący, w trakcie lub ukończony, więc możesz obserwować, jak Codex maszeruje w dół listy.

Zaawansowane wzorce

Iteracyjne udoskonalanie

Pętla sprzężenia zwrotnego

graph LR A[PRD] --> B[Plan] B --> C[Todo] C --> D[Implementacja] D --> E[Testowanie] E --> F[Feedback] F --> A

Po implementacji, zaktualizuj swoje dokumenty:

• PRD: Dodaj odkryte wymagania
• Plan: Udokumentuj decyzje architektoniczne
• Todo: Oznacz ukończone, dodaj nowe zadania

Współpraca zespołowa

Współdzielone dokumenty

• Przechowuj PRD w /docs/requirements/
• Trzymaj plany w /docs/architecture/
• Śledź todo w /docs/tasks/ lub narzędziu zarządzania projektami

Dzielenie kontekstu AI

• Odwołuj się do dokumentów z @docs/requirements/auth-prd.md
• Uwzględniaj decyzje zespołowe w promptach
• Używaj konsekwentnej terminologii w zespole

Integracja z istniejącymi przepływami pracy

Agile/Scrum

• PRD: Tworzone podczas planowania sprintu
• Plan: Spotkanie technicznego udoskonalenia
• Todo: Staje się elementami backlogu sprintu
• Każde todo może być mapowane na story point

Kanban

• PRD: Wchodzi do backlogu po zatwierdzeniu
• Plan: Tworzony przy przenoszeniu do “Analiza”
• Todo: Pojedyncze karty na tablicy
• Przepływ: Backlog → Analiza → Dev → Przegląd → Gotowe

Waterfall

• PRD: Część fazy wymagań
• Plan: Wynik fazy projektowania
• Todo: Lista kontrolna fazy rozwoju
• Każda faza formalnie przeglądana

Kiedy to się sypie

Metodologia zawodzi w przewidywalny sposób, gdy uruchamiasz ją na prawdziwych funkcjach. Oto tryby awarii i prompty ratunkowe, które sprowadzają Cię z powrotem na właściwy tor.

Uwaga

AI dryfuje od planu w trakcie implementacji. Trzy todo dalej model zaczyna wymyślać strukturę, której plan nigdy nie opisywał. Zakotwicz go ponownie w zatwierdzonym planie i konkretnym zadaniu.

You have started deviating from the approved plan. Re-read the plan and the current todo, then implement ONLY the current task as planned. List any place where the plan turned out to be wrong, but do not change course without my sign-off.

Uwaga

Todo pęcznieją powyżej czterech godzin. Zadanie, które uważałeś za małe, ciągle się rozrasta. To znak, że plan je niedoprecyzował. Podziel je, zanim wsiąkniesz w nie więcej czasu.

The current task is larger than estimated. Stop implementing and instead break it into sub-tasks of under two hours each, each with its own acceptance criterion. We will re-prioritize before continuing.

Uwaga

Plan kłóci się z istniejącą architekturą. Proponowane podejście duplikuje usługę lub łamie kontrakt, który już istnieje w bazie kodu. Wymuś uzgodnienie z prawdziwymi plikami.

The plan introduces a new pattern that conflicts with our existing code in @src/services/. Identify the conflict, then revise the plan to reuse what already exists. Flag anything that genuinely cannot be reused and explain why.

Uwaga

Pominąłeś plan i przeszedłeś prosto z PRD do todo. Nawet dla małych funkcji najpierw wygeneruj przynajmniej krótki plan techniczny — daje on AI kontekst architektoniczny i zapobiega niespójnym implementacjom między zadaniami.

Mierzenie sukcesu

Śledź te metryki, aby ulepszyć swój proces:

1. Wskaźnik ukończenia: procent todo ukończonych jak pierwotnie napisane
2. Wskaźnik przeróbek: jak często zaimplementowane funkcje wymagają zmian
3. Dokładność czasu: rzeczywisty kontra szacowany czas dla todo
4. Pokrycie wymagań: procent wymagań PRD pomyślnie zaimplementowanych
5. Jakość dokumentacji: kompletność dokumentacji po implementacji

Zespoły, które przyjmują przepływ pracy zaczynający od planu, zazwyczaj raportują szybsze dostarczanie i mniej regresji przy dużych migracjach, w dużej mierze dlatego, że faza planowania ujawnia przypadki brzegowe przed napisaniem jakiegokolwiek kodu, a nie podczas bolesnego przeglądu.

Jeszcze dwa prompty warte zachowania

Użyj ich, aby wzmocnić plan i ułożyć kolejność pracy, gdy todo już istnieją.

Wskazówka

Prompt do skopiowania, audytujący plan, zanim się na niego zdecydujesz:

Review this technical plan and identify: missing architectural components, scalability issues, security vulnerabilities, cost optimization opportunities, and technical-debt risks. For each, say whether it is a blocker or a nice-to-have, and propose a concrete change.

Wskazówka

Prompt do skopiowania, ustawiający kolejność listy todo:

Take this todo list and identify the critical path, suggest which tasks can run in parallel, estimate total completion time, highlight blockers and their dependencies, and recommend the order I should implement them in.

Wskazówka

Trzymaj swoje artefakty tam, gdzie AI je znajdzie. Przechowuj PRD w docs/requirements/, plany w docs/architecture/, a todo w docs/tasks/. Odwoływanie się do nich później przez @docs/requirements/auth-prd.md pozwala każdemu z trzech narzędzi ponownie wczytać decyzje, które już podjąłeś, i zachować spójność między funkcjami.

Co dalej

Podstawowa metodologia: PRD do planu do todo Lżejsza wersja szybkiego startu tego przepływu pracy.

Standardowe wzorce przepływu pracy Jak ta metodologia wpasowuje się w szerszą pętlę Planuj, Wykonuj, Weryfikuj.

Rozwój sterowany testami z AI Steruj każdym todo testem, który się nie powiedzie, zanim AI je zaimplementuje.

Projektowanie sterowane domeną Utrzymuj plany w zgodzie z modelem domeny i kontekstami ograniczonymi.