Najpierw specyfikacja.I czytasz ją przed kodem.

Pętla: specyfikacja, przegląd, plan, przegląd, zadania, build

Zamiast jednego wielkiego promptu i stosu kodu praca przechodzi przez dokumenty, a Ty sprawdzasz każdy, zanim powstanie następny.

1. Specyfikacja: co i dlaczego

   Co funkcja ma robić, dla kogo i czego nie ma robić. Jeszcze bez nazw plików i wyborów technologii.

2. Plan: jak

   Podejście: które części się zmieniają, w jakiej kolejności, z jakim ryzykiem. Plan odpowiada przed specyfikacją.

3. Zadania: małe kroki

   Checklista, którą agent może przechodzić i odhaczać, każde zadanie na tyle małe, by dało się je sprawdzić.

4. Build

   Dopiero teraz agent pisze kod, według dokumentów, które już przeczytano.

Krótki szablon specyfikacji

Specyfikacja nie musi być długa. Sześć nagłówków wystarczy, by wyłapać większość nieporozumień:

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goals i Open questions to te, które ludzie pomijają, a agenci potrzebują najbardziej. Agent, któremu powiedziano, czego nie budować i co jest jeszcze nierozstrzygnięte, pyta zamiast zgadywać.

Jak to zrobić w Claude Code, Codex i Cursor

Wszystkie trzy potrafią pisać dokumenty i każdy ma plan mode do etapu planowania: plan mode w Claude Code, plan mode w Codex i plan mode w Cursor.

Aby etap przeglądu był automatyczny, wpisz jedną zasadę w CLAUDE.md lub AGENTS.md: po napisaniu specyfikacji lub planu wyślij go do przeglądu w DotMD przez request_review i czekaj. Agent zatrzymuje się wtedy po każdym dokumencie i czeka na Twoje komentarze lub akceptację, nie zużywając tokenów. DotMD może dodać tę zasadę za Ciebie: zobacz CLAUDE.md i AGENTS.md.

Przegląd, który się skaluje

Czat to kiepskie miejsce na przegląd dokumentu. Zamiast tego czytasz specyfikację sformatowaną w DotMD, zaznaczasz błędny fragment i naciskasz ⌥⌘M. Komentarz jest przypięty do swoich linii, więc agent dokładnie wie, co masz na myśli. Możesz napisać wszystkie komentarze najpierw i wysłać je jednym razem.

Gdy agent je poprawi, każda zmiana jest pokazana w pliku: stary tekst na czerwono, nowy na zielono, obok komentarza, na który odpowiada. Accept lub Reopen dla każdej. DotMD wypisuje też zmiany, o które nikt nie prosił. Zobacz Sprawdzanie zmian.

Dla drugiej opinii pozwól najpierw przejrzeć innemu agentowi. Specyfikacja napisana przez Claude Code i skomentowana przez Codex trafia do Ciebie z oczywistymi lukami już zaznaczonymi, a Ty decydujesz, które uwagi dostanie autor: Agent sprawdza agenta.

Narzędzia do programowania ze specyfikacją

• Zwykły Markdown w repozytorium. Folder docs/specs i szablon powyżej to kompletna konfiguracja.
• Plan mode. Własny sposób każdego agenta na planowanie przed budowaniem.
• GitHub Spec Kit. Open source’owy zestaw narzędzi, który daje Twojemu agentowi polecenia na każdy krok i pisze za Ciebie spec.md, plan.md i tasks.md: GitHub Spec Kit.

Cokolwiek wybierzesz, dokumenty to pliki Markdown, a DotMD czyta każdy z nich.

Pytania o programowanie ze specyfikacją

Więcej pytań