Od PRD do planu i zadań w Cursorze

Proces PRD w Cursorze zamienia dokument wymagań produktowych w dwa zacommitowane pliki i serię commitów: spec.md z ponumerowanymi kryteriami akceptacji, plan.md przygotowany w Plan Mode z listą zadań oraz po jednym commicie na zadanie z dowodem z testów. Każde zadanie startuje w nowym czacie, który czyta plan.md, więc kilkudniowa funkcja przetrwa zamknięte czaty i da się ją sprawdzić względem kryteriów.

Aktualność dokumentacji

Zakres: linia Cursor 3.x; aktualnym wydaniem na 2026-10-12 jest Cursor 3.24 (2026-10-09, notatki o wydaniach Cursora). Pomoc Cursora mówi, że Shift+Tab przełącza kolejne tryby agenta (Agent, Ask, Plan i Debug), a przegląd agenta w dokumentacji Cursora, że checkpointy są przechowywane lokalnie, osobno od Gita, a ich przywrócenie cofa tylko pliki (oba sprawdzone 2026-10-12). Plan Mode i Bugbot zweryfikowano po raz pierwszy na cursor.com 28 sierpnia 2026 r. Ta strona opiera każde cofnięcie zmian na gicie.

Twój product manager wrzuca dwustronicowy PRD systemu powiadomień: e-mail i push, preferencje per typ, śledzenie dostarczenia. Prosisz agenta Cursora, żeby to zbudował, a po jednym popołudniu masz pół serwisu e-mailowego, schemat bazy, na który nikt się nie zgodził, i żadnego sposobu, by powiedzieć, któremu wymaganiu służy która zmiana. Ta strona jest dla programistów, którzy mają już reguły projektu i stoją przed funkcją za dużą na jeden czat, oraz dla tech leadów, którzy chcą przejrzeć plan, zanim powstanie kod.

Co daje ci proces PRD w Cursorze

• Prompt, który czyta PRD pod kątem luk i zapisuje spec.md z ponumerowanymi, testowalnymi kryteriami akceptacji.
• Prompt do Plan Mode, który tworzy listę zadań, w której każde zadanie wskazuje swoje pliki, kryteria i polecenie, które je dowodzi.
• Prompt na jedno zadanie w czystym czacie, dzięki czemu długie rozmowy przestają odpływać od planu.
• Kontrolę identyfikowalności (traceability), która dowodzi, że każde kryterium ma test, który potrafi nie przejść. To zastępuje czytanie całego diffu.
• Sposób na zmianę planu w połowie pracy bez utraty zapisu, dlaczego ją wprowadzono.

Kiedy PRD zasługuje na osobny proces?

Sięgnij po tę stronę, gdy funkcja nie mieści się w jednym czacie. Jeśli opiszesz ją pięcioma kryteriami akceptacji i skończysz za jednym posiedzeniem, wystarczy krótsza pętla z przewodnika zbuduj swoją pierwszą funkcję z pomocą AI.

Sygnał	Pętla w jednym czacie	Proces PRD
Kryteria akceptacji	Mniej więcej do pięciu, spisane przez ciebie	Więcej, niż utrzymasz w głowie, albo spisane przez kogoś innego
Sesje	Jedno posiedzenie	Kilka dni albo kilka osób
Gdzie żyje plan	W czacie	W plan.md, zacommitowanym i przejrzanym
Kto zatwierdza plan	Ty	Ty, a do tego product owner (kryteria) i tech lead (zmiany o wyższym ryzyku)

Nazwy plików pochodzą z łańcucha artefaktów, którego używa cały serwis: PRD pełni rolę intent.md, kryteria akceptacji trafiają do spec.md, a plan z zadaniami do plan.md. Do tego przewodnika nie potrzebujesz całego łańcucha, tylko dwóch ostatnich plików.

Przygotuj repozytorium, zanim wkleisz PRD

1. Zacznij od czystego drzewa roboczego na gałęzi funkcji, z jednym katalogiem na jej dokumenty. W terminalu:

   git status --short                      # must print nothing
   git switch -c feat/notifications
   mkdir -p docs/features/notifications

2. Zapisz PRD jako docs/features/notifications/prd.md. Jeśli PRD jest zgłoszeniem na GitHubie, agent może je przeczytać przez serwer GitHub MCP. Dodaj go do ~/.cursor/mcp.json, czyli pliku na poziomie użytkownika, którego nigdy nie commitujesz, token trzymaj w zmiennej środowiskowej, a serwer ustaw tylko do odczytu, bo do przeczytania PRD nie potrzebujesz narzędzi zapisu:

   {
     "mcpServers": {
       "github": {
         "url": "https://api.githubcopilot.com/mcp/",
         "headers": {
           "Authorization": "Bearer ${env:GITHUB_PAT}",
           "X-MCP-Toolsets": "context,repos,issues",
           "X-MCP-Readonly": "true"
         }
       }
     }
   }

   Jeśli twoja wersja Cursora nie rozwija ${env:GITHUB_PAT} (tę interpolację sprawdzono tylko na podstawie fragmentu dokumentacji), wklej sam token i trzymaj ~/.cursor/mcp.json poza każdym repozytorium.

   Zakresy tokenu i ustawienia tylko do odczytu opisuje przewodnik po serwerze GitHub MCP, a pozostałe serwery konfiguracja MCP w Cursorze.

3. Sprawdź, że testy, sprawdzanie typów i lint uruchamiasz każdy jednym poleceniem. Ten przykład używa npm test, npm run typecheck i npm run lint. Każde zadanie w planie kończy się jednym z tych poleceń, więc brak któregoś blokuje cały proces; zobacz jak przygotować kod pod agenta.

Faza 1: zamień PRD w kryteria akceptacji

PRD opisuje, czego chce product owner. Agent potrzebuje stwierdzeń, które da się przetestować. Pierwszy prompt przekłada jedno na drugie i wypisuje, czego PRD nie rozstrzyga, zamiast pozwolić agentowi zgadywać. Uruchom go w nowym, zwykłym czacie agenta zamiast w Plan Mode, żeby agent od razu zapisał spec.md.

Prompt do skopiowania: przeczytaj PRD pod kątem luk i zapisz spec.md

Read @docs/features/notifications/prd.md. Do not write any code.

1. Ask me up to five clarifying questions about anything ambiguous or
   missing: failure behaviour, limits, permissions, data retention,
   and what is explicitly out of scope. Wait for my answers.
2. Then write docs/features/notifications/spec.md with these sections:
   - Acceptance criteria: numbered AC1, AC2, ... Each one is a single
     observable behaviour that an automated test can check.
   - Non-functional requirements, each with a number (latency, volume,
     retry limits).
   - Out of scope.
   - Open questions: anything I could not answer. Do not invent answers.
3. After each criterion, name the PRD section it comes from.
Create or edit no other file.

Przeczytaj spec.md uważnie. To jedyny dokument w tym procesie, który czytasz linijka po linijce, bo wszystkie późniejsze kontrole mierzą się właśnie z nim. Szukaj trzech wad:

• Mglistych kryteriów. Przy „Użytkownicy zarządzają preferencjami” żaden test nie może paść. „Użytkownik może wyłączyć e-mail dla typu comment i potem żaden e-mail tego typu nie trafia do kolejki” — może.
• Brakujących ścieżek błędów. PRD rzadko mówi, co się dzieje, gdy dostawca e-maili nie odpowiada. Dodaj na to kryterium albo wpisz sprawę do Open questions.
• Kryteriów bez źródła w PRD. Agent dopisał wymaganie, o które nikt nie prosił. Usuń je albo uzyskaj akceptację product ownera.

Wyślij product ownerowi spec.md, nie czat. Jego akceptacja kryteriów to pierwsze zatwierdzenie. Potem zacommituj plik:

git add docs/features/notifications && git commit -m "docs: notifications spec (AC1-AC9)"

Pełną metodę opisuje przewodnik kryteria akceptacji, których agent nie zrozumie opacznie.

Faza 2: przygotuj plan w Plan Mode

Otwórz nowy czat i przełącz agenta w Plan Mode (Shift+Tab przełącza kolejne tryby), który tworzy plan implementacji, zanim napisze jakikolwiek kod. Nowy czat ma znaczenie: rozmowa z fazy 1 przechowuje twoje odpowiedzi jako historię czatu, a spec.md jako plik. Planuj na podstawie pliku.

Prompt do skopiowania: zaplanuj funkcję względem specyfikacji

Plan the notification feature described in
@docs/features/notifications/spec.md. Do not write code yet.

Before planning, find how this codebase already handles database
migrations, background jobs, outbound HTTP calls, and configuration.
List the files you read.

The plan must contain:
- A task list with checkboxes. Each task fits in one reviewable commit.
- For each task: the files it creates or changes, the acceptance
  criteria it satisfies (AC numbers), the test that proves it, and the
  command that runs that test.
- The order of tasks, with each dependency stated ("T4 needs T2").
- Any new dependency, marked NEW DEPENDENCY with a reason. Prefer none.
- A final "Proof" section: the commands that must pass before the PR.

Every AC must appear in at least one task. If an AC cannot be planned
without answering an open question, stop and tell me which one.

Zanim zaakceptujesz plan, przejdź przez tę listę kontrolną:

• Każde kryterium ze spec.md ma co najmniej jedno zadanie i jeden nazwany test. Kryterium bez zadania to wymaganie, które nie trafi na produkcję.
• Każde zadanie wymienia swoje pliki. Zadanie „zaktualizuj odpowiednie serwisy” nie ma zakresu, który sprawdzisz przez git diff --stat.
• Pierwsze zadanie daje coś, co da się przetestować samodzielnie, na przykład migrację z testem, a nie szkielet wszystkich warstw naraz.
• Nowe pliki trzymają się wzorców, które agent według własnych słów przeczytał. Nowa biblioteka kolejek albo drugi klient HTTP to pytanie do rozstrzygnięcia teraz, a nie po instalacji.

Poprawiaj plan w tym samym czacie („Użyj istniejącego runnera z jobs/, a nie nowej kolejki”), aż lista kontrolna przejdzie. Poprawka na tym etapie kosztuje jedno zdanie. Ta sama poprawka po trzech zadaniach kosztuje przepisanie kodu.

Zapisz plan tam, gdzie przeczyta go recenzent i kolejne czaty

Plan, który istnieje tylko w czacie albo tylko na twoim komputerze, znika przy następnej sesji i jest niewidoczny dla recenzenta. Po akceptacji planu poproś agenta, żeby zapisał wersję ostateczną jako docs/features/notifications/plan.md obok spec.md, zanim przełączysz tryb: przełączenie zaczyna nowe okno kontekstu (pomoc Cursora, sprawdzone 2026-10-12), więc plan, który istnieje tylko w czacie, nie pójdzie za tobą. Potem zacommituj plik. Zacommitowany plik powinien wyglądać tak:

# Plan: notifications (spec: ./spec.md)

## Tasks
- [ ] T1 Migration: notification_preferences table.
      Files: db/migrations/0042_notification_prefs.sql, db/prefs.test.ts
      Covers: AC2 · Proof: npm test -- db/prefs.test.ts
- [ ] T2 Preferences API: GET/PUT /api/notification-preferences.
      Files: src/api/preferences.ts, src/api/preferences.test.ts
      Covers: AC1, AC2 · Needs: T1 · Proof: npm test -- src/api/preferences.test.ts

## Proof
npm test && npm run typecheck && npm run lint

Przy funkcji o wyższym ryzyku otwórz szkic pull requesta, który zawiera tylko spec.md i plan.md, i poproś tech leada o przegląd. Recenzent, który zaakceptował plan przed powstaniem kodu, później sprawdza kod względem uzgodnionej listy, a nie własnych domysłów, o co ci chodziło.

Faza 3: jedno zadanie na jeden czat

Wykonuj zadania po kolei, już poza Plan Mode. Każde zadanie dostaje nowy czat, który startuje od plan.md, więc agent pracuje według uzgodnionego planu, a nie końcówki długiej rozmowy.

Prompt do skopiowania: wykonaj następne zadanie z plan.md

Read @docs/features/notifications/plan.md and
@docs/features/notifications/spec.md.
Implement the first unchecked task only. Change only the files that
task lists. If you need another file, a new dependency, or a different
design, stop and explain why instead of doing it.

Write or update the test the task names, then run its Proof command
and show me the output. If a test fails twice for the same reason,
stop and tell me what you observed.
When the Proof command passes, tick that task's checkbox in plan.md.
Do not start the next task.

Po każdym zadaniu sprawdź zakres i zacommituj zmiany przed następnym czatem:

git diff --stat                    # only the files the task lists, plus plan.md
git add -A && git commit -m "feat(notifications): T2 preferences API (AC1, AC2)"

Commit jest twoim punktem powrotu. Jeśli agent zboczy z kursu, wróć do niego przez git restore . i git clean -fd, a potem powtórz prompt z wypisaną listą plików. Gdy zadania nie dzielą plików, możesz je uruchomić równolegle w osobnych worktree. Rób to dopiero wtedy, gdy pętla z jednym zadaniem stanie się rutyną.

Udowodnij zgodność ze specyfikacją bez czytania każdej linijki

Testy napisane przez agenta, które przechodzą, dowodzą tylko tego, że kod zgadza się z tymi testami. Zanim otworzysz pull request, każ agentowi pokazać, że każde kryterium ma test, który pada, gdy zachowanie się psuje.

Prompt do skopiowania: audyt pokrycia kryteriów testami

Using @docs/features/notifications/spec.md and the commits on this
branch, build a table: AC number | test file and test name | task.

Then, for each AC, one at a time:
1. Break the implementation in the smallest way that violates it.
2. Run the named test and confirm it fails.
3. Restore the implementation exactly and confirm the suite passes.

Do not edit any test file during this task. Add a column
"failed when broken" (yes/no). List any AC with no test, and any test
that maps to no AC. Finish with `git status --short`, which must be empty.

Wartość no w tej kolumnie to prawdziwe znalezisko: kryterium nie ma testu, który mógłby paść. Poproś o taki test i powtórz audyt. Resztę dowodów zbierz samodzielnie:

1. Uruchom w terminalu sekcję Proof z planu i potwierdź, że przechodzi na czystym checkoucie:

   npm test && npm run typecheck && npm run lint

2. Porównaj zakres zmian z planem. Każdy plik z tej listy powinien występować w którymś zadaniu:

   git diff --stat main...HEAD

3. Sprawdź, że po drodze nie osłabiono żadnego testu:

   git diff main...HEAD -- '*.test.ts' | grep -E '^-.*expect\(|^\+.*\.(skip|only)\('

   Pusty wynik to ten, na który czekasz. Ochrona wyroczni testowej pokazuje, jak wymusić to w CI zamiast ręcznie.

4. Otwórz pull request z odnośnikami do spec.md, plan.md i tabeli pokrycia w opisie. Jeśli twój zespół używa Bugbota, przejrzy on pull request pod kątem błędów, problemów z bezpieczeństwem i jakością kodu. Traktuj jego uwagi jako materiał dla recenzenta, a nie jako bramkę.

Kto zatwierdza: product owner zaakceptował kryteria w fazie 1, a recenzent akceptuje teraz trzy rzeczy: każde kryterium ma test, który padł po zepsuciu kodu, zakres zgadza się z planem, a bramki przechodzą. Czytanie kodu zostaje dla tego, czego dowody nie obejmują, na przykład kontroli uprawnień w API preferencji. Gdzie przebiega ta granica, wyjaśnia strona dowody zamiast czytania diffów.

Zmień plan, gdy PRD zmienia się w trakcie budowy

Product ownerzy zmieniają zdanie po zadaniu T3. Nie zaczynaj od łatania kodu. Zmień specyfikację, potem plan, a dopiero potem kod, żeby zapis pozostał prawdziwy.

Prompt do skopiowania: wprowadź zmianę wymagań do specyfikacji i planu

The product owner changed a requirement: push notifications are out
of scope for this release; email only.

1. Update @docs/features/notifications/spec.md: move the affected
   ACs to Out of scope and note the date and reason.
2. Update @docs/features/notifications/plan.md: list every task,
   done or not, that the change affects, and say for each one whether
   to remove it, change it, or add a follow-up task to undo work already
   committed.
Show me both diffs. Do not change any code until I approve them.

Zmianę specyfikacji i planu zacommituj osobno, z powodem w opisie commita. Potem wróć do promptu na jedno zadanie. Recenzent widzi teraz, dlaczego zniknęło T5, czego sam diff kodu nigdy nie pokaże. Jak utrzymać specyfikację jako źródło prawdy na dłuższą metę, opisuje spec-driven development.

Co psuje się w procesie PRD i jak z tego wyjść

Objaw	Prawdopodobna przyczyna	Jak naprawić
Plan jest ogólnikowy: „przygotuj warstwę serwisów”, „dodaj testy”	spec.md ma mgliste kryteria albo prompt planu nie wymagał plików i dowodu dla każdego zadania	Doprecyzuj kryteria w spec.md i uruchom prompt planu ponownie w nowym czacie
Agent robi dwa zadania naraz	Prompt nie mówił „tylko pierwsze niezaznaczone zadanie” albo czat jest długi	git restore . do ostatniego commita, nowy czat i prompt na jedno zadanie bez zmian
Plan wymyśla kolejkę, klienta albo tabelę, które już masz	Agent nie przeczytał twojego kodu albo reguły nie opisują konwencji	Poproś o listę przeczytanych plików, popraw plan i dopisz konwencję do reguły projektu
Pola wyboru w plan.md są zaznaczone, a polecenie Proof nie przechodzi	Agent zaznaczył pole, zanim test przeszedł	Odznacz je, uruchom polecenie Proof samodzielnie i za dowód uznawaj tylko wynik z własnego terminala
Otwarte pytanie zostaje rozstrzygnięte w kodzie	Nikt nie wpisał odpowiedzi do spec.md	Zatrzymaj pracę, zapisz odpowiedź w spec.md razem z product ownerem i sprawdź względem niej zadanie, którego dotyczy
Agent kręci się w kółko wokół jednego testu	Nieudane próby w czacie ciągną kolejną w tę samą stronę	Wróć do ostatniego commita i otwórz nowy czat z własną diagnozą; zobacz wychodzenie z błędów w Cursorze

Dokąd dalej z pracą opartą na PRD w Cursorze

Konfiguracja MCP w Cursorze Podłącz agenta do trackera zgłoszeń, bazy danych i przeglądarki, żeby czytał PRD i sam sprawdzał swoją pracę.

Łańcuch artefaktów Pełna droga od intencji do produkcji, z szablonami i właścicielem każdego pliku.

Zbuduj swoją pierwszą funkcję z pomocą AI Wersja tej pętli w jednym czacie, dla funkcji, które skończysz za jednym posiedzeniem.

Pakiet dowodów Zbierz tabelę pokrycia, zakres zmian i wyniki bramek w jeden manifest, który recenzent może zatwierdzić.

Korzystasz też z innego agenta? Ten sam proces od PRD do planu w terminalu opisuje strona proces PRD w Claude Code, a wersję pętli „najpierw plan, potem budowa” w Codeksie znajdziesz w przewodniku twoje pierwsze zadanie w Codeksie. Procedurę zespołową dla każdego pliku opisują strony etapów Design i Build.