Od mglistego zgłoszenia do planu, który agent wykona.
Jeden przykład krok po kroku pokazuje trzy pliki, od których zaczyna się reszta biblioteki: intent.md, spec.md i plan.md. Potem ponad 100 przepisów, każdy z promptem i sprawdzeniem, które dowodzi wyniku.
249,99 zł jednorazowo za 12 miesięcy dostępu. Nic się samo nie odnawia. Zwrot w ciągu 30 dni przy pierwszym zakupie.
- Pliki pisane, zanim agent zacznie budować
- 3
- Przepisy do skopiowania
- 100+
- Obszary
- 7
- Narzędzia, dla których napisano przepisy
- 3
Trzy pliki, każdy czytany przez następny etap.
Najpierw intencja, potem specyfikacja, potem plan. Każdy plik trafia do repozytorium, a wskazana osoba akceptuje go, zanim zacznie się następny. Agent może naszkicować każdy z nich, ale nie akceptuje własnej pracy.
-
intent/notifications/intent.md
Intent: Notifications when a teammate comments on a document
Problem
WHAT_IS_BROKEN_OR_MISSING
Proposed outcome
In-app and email notifications when a teammate comments on a document.
Affected users and systems
Teammates on a document.
Constraints
Follow the existing API conventions.
Open questions
OPEN_QUESTIONS
- Akceptuje
- Product owner
- Gotowe, gdy
- Problem, rezultat i ograniczenia są opisane; otwarte pytania są wypisane, a nie zgadnięte
Gotowy prompt: wywiad, który kończy się intencją Pokaż prompt: wywiad, który kończy się intencją
I want to add in-app and email notifications when a teammate comments on a document. Interview me before writing anything. Ask one question at a time about users, triggers, delivery channels, opt-out, volume, edge cases, and constraints, and dig into the parts I have not thought about. When we have covered everything, write intent/notifications/intent.md with the sections Problem, Proposed outcome, Affected users and systems, Constraints, and Open questions. Put anything I could not answer under Open questions. Do not propose a design and do not write code.
-
intent/notifications/spec.md
Spec: Notifications when a teammate comments on a document
(from intent.md, accepted DATE)
Requirements and acceptance criteria
R1: In-app and email notifications when a teammate comments on a document. Accepted when: CHECKABLE_CRITERION
Architecture and design
DESIGN_DETAILS
Out of scope
OUT_OF_SCOPE
Skills and policies applied
Security: POLICIES_APPLIED
Brand and UX: GUIDELINES_APPLIED
Flagged concerns
CONCERNS_FOR_POLICY_OWNERS
- Akceptuje
- Product owner, przy pracy wyższego ryzyka także tech lead
- Gotowe, gdy
- Każde wymaganie ma kryterium akceptacji, które test może sprawdzić
Gotowy prompt: zestaw specyfikację z bazą kodu Pokaż prompt: zestaw specyfikację z bazą kodu
Read intent/notifications/spec.md. Do not write or change any files. 1. Restate each requirement in one sentence. 2. List every ambiguity or gap, and the question that would close it. 3. Find the existing code, tables, and API patterns this feature touches, with file paths. 4. Flag every place where the spec conflicts with the current architecture, for example a new table where an existing one could be extended. 5. List each requirement that has no testable acceptance criterion.
-
intent/notifications/plan.md
Plan: Notifications when a teammate comments on a document
(from spec.md, accepted DATE)
Files that change
FILE_LIST_WITH_REFERENCE_PATTERNS
Decisions
DECISION: a new
notificationstable or extendingevents, CHOICE, REASONTasks
1. Migration (files: FILES). Accepted when: CHECK. Test: TEST_COMMAND
2. API (files: FILES). Accepted when: CHECK. Test: TEST_COMMAND
3. UI (files: FILES). Accepted when: CHECK. Test: TEST_COMMAND
Risks
RISKS
Proof
COMMANDS_THAT_SHOW_THE_CHANGE_WORKS
- Akceptuje
- Inżynier (praca rutynowa); tech lead lub architekt (wyższe ryzyko)
- Gotowe, gdy
- Każde zadanie wskazuje swoje pliki i polecenie, które potwierdza jego wykonanie
Gotowy prompt: szkic plan.md z zadaniami Pokaż prompt: szkic plan.md z zadaniami
Using intent/notifications/spec.md and what you found in the codebase, write intent/notifications/plan.md with these sections: - Files that change, with the existing file you use as the pattern for each. - Decisions: every choice with a real trade-off, the options, and your pick. - Tasks: an ordered checklist (- [ ]). Each task fits one focused session, names its files, states its acceptance check, and is followed by the test that proves it. Order by dependency: migration, then API, then UI. - Risks. - Proof: the exact commands that show the whole change works. Prefer dependencies already in package.json. Do not implement anything.
Gdzie wychodzi na jaw kolidująca tabela.
Zgłoszenie brzmi „Dodaj powiadomienia dla użytkowników”. Wklejone wprost agentowi, daje 400 linii kodu, które wyglądają wiarygodnie, pomijają połowę wymagań i wymyślają tabelę notifications kolidującą z twoją tabelą events. Agent podjął decyzje architektoniczne, o które nikt go nie prosił, bo nic zapisanego nie mówiło mu, że ma postąpić inaczej.
Plan dodaje tabelęnotifications. Jakie są kompromisy względem rozszerzeniaeventsi które rozwiązanie pasuje do naszych istniejących wzorców?
-
Zapisz intencję
Niech agent przeprowadzi z tobą wywiad, zamiast pisać intencję sam. Zacommituj wynik i poproś product ownera o akceptację.
-
Napisz specyfikację, a potem każ agentowi znaleźć w niej luki
Zanim powstanie jakikolwiek plan, otwórz nową sesję. Ten krok wyłapuje kolidującą tabelę, zanim ktokolwiek ją napisze.
-
Naszkicuj plan w trybie planowania
Tryb planowania pozwala agentowi czytać kod bez zmieniania go. Poproś o plan, który wykorzystuje to, co już istnieje, i kończy się listą zadań.
-
Wykonuj jedno zadanie na turę
Każde zadanie jest na tyle małe, że da się je sprawdzić i wyrzucić. Gdy agent pomyli się przy zadaniu 7, tracisz zadanie 7, a nie całą funkcję.
-
Sprawdź diff względem łańcucha
Uruchom przegląd, który porównuje to, co zbudowano, z tym, co zaakceptowano: pliki, których plan nie wymienia, i odhaczone zadania bez testu.
-
Zmerguj i domknij pętlę
Pull request niesie wyniki review i dowody testów. Incydent albo brakujące wymaganie staje się następnym
intent.md.
Ten sam łańcuch w każdym narzędziu.
Różni się tylko to, jak utrzymujesz agenta w trybie tylko do odczytu, gdy planuje. We wszystkich trzech plan liczy się dopiero jako zacommitowany plan.md: ten plik czytają CI, agenci recenzujący i następna sesja.
| Narzędzie | Tryb planowania | Worktree |
|---|---|---|
| Claude Code | Tryb planowania włączysz przez Shift+Tab, /plan albo claude --permission-mode plan. Od v2.1.283 (oba kanały wydań na 2026-10-12) sesje interaktywne w terminalu i VS Code startują w trybie auto, więc na tryb planowania przełącz się świadomie. | claude -w notifications uruchamia pracę w nowym worktree Gita, a claude -c kontynuuje ostatnią rozmowę. |
| Codex | Tryb planowania włączysz przez /plan w CLI. | codex --worktree uruchamia sesję w nowym, zarządzanym worktree Gita (v0.157.1), a codex resume --last wznawia ostatnią sesję. |
| Cursor | Wybierz Plan w selektorze trybu agenta. | Worktrees „let Agent work in isolated Git checkouts” (dokumentacja Cursora, sprawdzone 2026-08-28), dzięki czemu równoległe zadanie nie dotyka twojej gałęzi roboczej. |
Przepisy według obszaru.
Każdy przepis łączy prompt ze sprawdzeniem, które dowodzi wyniku: testem, który najpierw nie przechodzi, kontrolą typów, buildem albo bramką, którą możesz uruchomić.
Pokaż jeden obszar
Frontend
6 stronBackend
12 stronBazy danych
5 stronDane
1 stronaDevOps
6 stronMobile
6 stronObsługa błędów
4 stronyPrzepis zaczyna się od przypięcia tego, w czym agent wciąż się myli.
Agenci uczyli się Reacta na kodzie z wielu lat: z Reacta 16–18, TanStack Table v8 i tutoriali Create React App. Bez przypięcia wersji odtwarzają właśnie to. Przepisy dla Reacta zaczynają się od bloku do CLAUDE.md, AGENTS.md albo reguły Cursora, a potem sprawdzają każdy zamiennik w opublikowanych typach.
Fragment strony „Przepisy dla Reacta” (aktualizacja: 2026-10-12). Tabela jest z tej samej strony, z nagłówkiem „Stan na 2026-09-26”; pokazujemy 3 z 6 wierszy. Otwórz stronę (w cenie Toolkitu)
CLAUDE.md, AGENTS.md albo reguła Cursora Pokaż blok do przypięcia
## Frontend stack (React)
- React 19.3, TypeScript strict, Vite 8, Vitest 5 + Testing Library, Playwright for e2e.
- Server state: TanStack Query v5. Client state: Zustand 5. Forms: React Hook Form 7 + Zod 4
via @hookform/resolvers. Tables: TanStack Table v9 (`useTable` + `tableFeatures`).
- Never write: useReactTable, cacheTime, `import { ReactComponent } from './x.svg'`,
process.env.REACT_APP_*, z.string().email(), `as any`, useState+useEffect loading flags
for server data.
- Before you say a task is done, run `npm run verify` and paste the last 20 lines of output.
- Tests query by role and label, never by class name or test id unless no role exists. | Agent pisze | Stan na 2026-09-26 | Pisz zamiast tego |
|---|---|---|
useReactTable(options) | Nieeksportowane przez @tanstack/react-table 9.2.4; jest tylko useLegacyTable z /legacy, oznaczone jako przestarzałe | useTable({ ...options, features }) z tableFeatures() |
cacheTime w zapytaniu | Brak w typach @tanstack/query-core v5 | gcTime |
z.string().email() | @deprecated Use z.email() instead w Zod 4.6.5 | z.email() |
Idź o stronę dalej.
Trzy darmowe strony obok tej.
Pytania o przykłady.
Coś innego? Napisz na support@developertoolkit.ai.
Czy agent nie napisze tych plików sam?
Może naszkicować każdy z nich. Łańcuch dodaje kolejność i akceptację: każdy plik trafia do commita, wskazana osoba go akceptuje, a następny etap czyta ten plik, a nie czat. Bez tego agent podejmuje decyzje architektoniczne, o które nikt go nie prosił.
Czy przy każdej zmianie potrzebuję wszystkich trzech plików?
Zmiana w jednym pliku może trafić prosto do zadania. Wszystko, co dotyka schematu, publicznego API albo więcej niż jednej warstwy, dostaje co najmniej spec.md i plan.md, bo właśnie tam wyłapuje się błędy w rodzaju kolidującej tabeli.
Kto akceptuje każdy plik?
Product owner akceptuje intent.md i spec.md, a przy pracy wyższego ryzyka do specyfikacji dołącza tech lead. plan.md akceptuje inżynier przy pracy rutynowej, a tech lead albo architekt przy wyższym ryzyku. Agent może naszkicować każdy plik, ale akceptuje go człowiek.
Czy przepisy działają w Claude Code, Codeksie i Cursorze?
Przepisy napisano dla Claude Code, Codeksa i Cursora. Każdy łączy prompt ze sprawdzeniem, które możesz uruchomić: kontrolą typów, testami albo buildem. Gdy plik różni się między narzędziami, strona o tym mówi: CLAUDE.md dla Claude Code, AGENTS.md dla Codeksa i reguła projektu dla Cursora.
Czy mogę coś z tego przeczytać, zanim zapłacę?
Szablony i prompty z tej strony możesz kopiować od razu. Strony z przepisami wliczają się do darmowych artykułów w miesiącu, a w całości otwiera je Toolkit. Sekcje „Zacznij tutaj” i „Drabina autonomii” możesz czytać za darmo, a darmowy przewodnik o poziomie 4 opisuje cztery artefakty, które powstają przed długim przebiegiem.
Skąd wiem, że przepis jest aktualny?
Każda strona pokazuje datę ostatniej aktualizacji. Przepisy dla Reacta podają wersje pakietów, względem których je sprawdzono, oraz API, których agenci wciąż używają, choć już nie istnieją.
Używane przez zespoły inżynierskie w
- Grupa Morizon-Gratka
- Ringier Axel Springer
- TasteRay
Twórca wondel.ai Skills — 2,3k+ gwiazdek na GitHubie (otwiera się w nowej karcie)
Daj agentowi plan, który da się dokończyć.
Kup Toolkit i otwórz pełny przewodnik o łańcuchu artefaktów oraz ponad 100 przepisów, po angielsku lub po polsku.
249,99 zł jednorazowo za 12 miesięcy dostępu. Nic się samo nie odnawia. Zwrot w ciągu 30 dni przy pierwszym zakupie.