Planowanie z Cursorem: zaakceptowany plan przed pierwszą linią kodu

Sekcja planowania w Cursorze to trzy przewodniki dla programistów i tech leadów, które zamieniają cel w zaakceptowany plan, zanim agent zmieni jakikolwiek plik: start nowego projektu, projekt schematu bazy danych i wybór architektury. Każdy z nich korzysta z Plan Mode, który według Cursora tworzy „szczegółowe plany implementacji, zanim powstanie jakikolwiek kod”.

Prosisz agenta Cursora o „zaproszenia do zespołu”, a godzinę później na gałęzi jest 30 zmienionych plików opartych na tabeli ról, której nikt nie uzgodnił. Kod się kompiluje, ale struktura jest zła. Planowanie przenosi twój przegląd na jednostronicowy plan z testowalnymi kryteriami akceptacji, a diff porównujesz z tym kontraktem.

Na czym oparto tę stronę

Linia Cursor 3.x; aktualne wydanie na 2026-10-12 to Cursor 3.24 (2026-10-09, informacje o wydaniu Cursora). Dokumentacja Cursora wymienia cztery tryby agenta: Agent, Ask, Plan i Debug, a Shift+Tab przełącza je po kolei; Cmd+I (Ctrl+I w Windows i Linuksie) otwiera panel Agenta. Tryby uruchamiania to Auto-review, Allowlist i Run Everything, a Cursor nie wskazuje jednego domyślnego modelu (wszystko sprawdzone 2026-10-12). Plan Mode, Rules i worktrees zweryfikowano w dokumentacji Cursora po raz pierwszy 28 sierpnia 2026.

Wymaganie wstępne: Cursor zainstalowany i zalogowany, a polecenia testów, lintera i sprawdzania typów zapisane w regule projektu. Jeśli jeszcze tego nie masz, zacznij od szybkiego startu Cursora.

Którego przewodnika po planowaniu w Cursorze potrzebujesz?

Twoja sytuacja	Zacznij od	Z czym wychodzisz
Zaczynasz od pustego katalogu i luźnego opisu produktu	Nowy projekt z agentem Cursora	Spisany PRD, reguły projektu i działający szkielet zapisany w Git
Funkcja wymaga nowych tabel albo zmieniasz schemat, w którym są dane	Projektowanie schematu bazy danych z Cursorem	docs/data-model.md, testy ograniczeń i odwracalne migracje
Musisz wybrać między wariantami architektury albo podzielić lub zmigrować system	Projektowanie architektury z agentem Cursora	Podpisany ADR, regułę, która go przenosi, i testy w CI, które go egzekwują
Masz zgłoszenie funkcji w istniejącej bazie kodu	Od PRD do planu w Cursorze	Plan i listę zadań, przez którą przechodzi agent

Przeprowadź sesję planowania w Plan Mode

Tej sekwencji używasz w każdym z powyższych przewodników. Plan jest wart akceptacji tylko wtedy, gdy każde jego twierdzenie da się sprawdzić narzędziem.

1. Zapisz cel i ograniczenia w pliku, np. docs/intents/FEATURE.md, żeby plan miał źródło, na które możesz wskazać. Etap planowania w metodzie opisuje, co zawiera taki plik intencji.
2. Otwórz nowy czat i przełącz agenta w Plan Mode. Wklej pierwszy prompt poniżej. Agent czyta kod i pisze plan zakończony otwartymi pytaniami, o które prosi prompt; niczego nie edytuje.
3. Odpowiedz na otwarte pytania w pliku intencji, nie w czacie, a potem poproś o poprawiony plan.
4. Uruchom drugi prompt, żeby w drugim przebiegu agent podważył plan, zanim go zaakceptujesz.
5. Wyjdź z Plan Mode i poproś agenta, żeby przed pierwszą edycją zapisał zaakceptowany plan jako docs/plans/FEATURE.md.
6. Buduj z tego pliku po jednym kamieniu milowym, na osobnej gałęzi albo w worktree; zobacz checkpointy i gałęzie.

Prompt do skopiowania: plan, który da się sprawdzić

Read docs/intents/FEATURE.md and the code it touches. Do not edit any file.
Produce a plan with exactly these sections:
1. Current state: how the affected code works today, with path:line citations
   for every claim.
2. Acceptance criteria: 3-6 Given/When/Then statements, each mapped to the name
   of a test that fails before the change and passes after it.
3. Files to change, and files you must not touch (existing tests, migrations).
4. Milestones in order, each small enough to review and revert on its own.
5. Verification: the exact test, type-check and lint commands from the project rules.
6. Rollback: how to revert or switch the change off.
End with open questions instead of guessing.

Prompt do skopiowania: podważ plan, zanim go zaakceptujesz

Review the plan above against the codebase as a sceptical reviewer. Do not edit files.
- Check every path:line citation and list any that are wrong.
- Name any caller, background job, config or migration the plan misses.
- For each acceptance criterion, say how it could pass while the feature is broken,
  and tighten it.
- Flag any milestone that cannot be rolled back on its own.
Then output the revised plan with each change marked.

Jak sprawdzić wynik bez czytania każdej linii?

Plan staje się kontraktem, a bramki sprawdzają z nim kod:

• Najpierw testy. Każde kryterium akceptacji wskazuje test, który przed zmianą nie przechodzi. Przejście z czerwonego na zielony dowodzi, że zmieniło się zachowanie; zobacz wykonywalne kryteria akceptacji.
• Zakres. Diff dotyka tylko plików z listy zakresu w planie. git diff --stat main...HEAD pokazuje to na jednym ekranie.
• Bramki maszynowe. Sprawdzanie typów, linter i pełen zestaw testów to wymagane checki w CI; lokalny przebieg agenta jest tylko podglądem.
• Akceptacja. Plan funkcji akceptuje programista; plan, który zmienia decyzję architektoniczną, akceptuje tech lead. Po zbudowaniu recenzenci czytają plan, nazwy testów i wynik CI, a diff otwierają tylko tam, gdzie pakiet dowodów jest słaby.

Uzasadnienie tej zmiany znajdziesz w tekście dowody zamiast diffów.

Co się psuje przy planowaniu w Cursorze?

Objaw	Prawdopodobna przyczyna	Jak to naprawić
Plan to ogólnikowy konspekt	Prompt podał cel, a nie sekcje i ograniczenia	Użyj pierwszego promptu i wskaż mu plik intencji
Plan cytuje funkcje, które nie istnieją	Twierdzenia pisane z założeń	Uruchom prompt recenzujący i odrzuć każdy plan z błędnym cytowaniem
Agent edytował pliki w trakcie planowania	Czat nie był w Plan Mode	Odrzuć zmiany przez git restore . (albo git stash), a potem zacznij czat od nowa w Plan Mode; własny mechanizm cofania w Cursorze opisuje strona checkpointy i gałęzie
Implementacja rozjeżdża się z planem	Plan istniał tylko w czacie	Zapisz go w docs/plans/ i każdy czat budujący zaczynaj od „Follow docs/plans/FEATURE.md; stop and ask before deviating”
Każdy nowy czat od nowa podważa ustalone wybory	Decyzji nie zapisano tam, gdzie agent je czyta	Zapisz je w ADR i w regule projektu, tak jak pokazuje przewodnik po architekturze

Dokąd iść po akceptacji planu

• Spec-driven development: niech przedmiotem przeglądu będzie specyfikacja, a nie kod.
• Ten sam etap w innych narzędziach: planowanie z Claude Code i planowanie z Codex.

Budowanie z Cursorem Następny krok po akceptacji planu: realizacja kamień milowy po kamieniu milowym, na osobnej gałęzi i za tymi samymi bramkami