From a vague ticket to a plan an agent can build.
One walkthrough shows the three files the rest of the library assumes you have: intent.md, spec.md and plan.md. Then 100+ recipes, each a prompt paired with the check that proves the result.
$59.99 once for 12 months of access. Nothing renews on its own. 30-day refund on a first purchase.
- Files written before the agent builds
- 3
- Recipes to copy
- 100+
- Domains
- 7
- Tools the cookbook is written for
- 3
Three files, each read by the next stage.
Intent, then spec, then plan. Each is committed to the repository, and a named person accepts it before the next one starts. An agent can draft every file. It does not accept its own work.
-
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
- Accepted by
- Product owner
- Done when
- Problem, outcome, and constraints are stated; open questions are listed, not guessed
Copy-paste prompt: interview me into an intent Show the prompt: interview me into an intent
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
- Accepted by
- Product owner, plus a tech lead on higher-risk work
- Done when
- Every requirement has an acceptance criterion that a test can check
Copy-paste prompt: read the spec against the codebase Show the prompt: read the spec against the codebase
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
- Accepted by
- Engineer (routine); tech lead or architect (higher risk)
- Done when
- Each task names its files and the command that proves it
Copy-paste prompt: draft plan.md with tasks Show the prompt: draft plan.md with tasks
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.
Where the clashing table gets caught.
The ticket says “Add user notifications”. Pasted straight into an agent, it writes 400 lines that look plausible, miss half the requirements and invent a notifications table that clashes with your events table. The agent made architectural decisions nobody asked it to make, and nothing written down told it otherwise.
The plan adds anotificationstable. What are the trade-offs against extendingevents, and which one matches our existing patterns?
-
Capture the intent
Make the agent interview you instead of writing the intent alone. Commit the result and have the product owner accept it.
-
Write the spec, then have the agent read it for gaps
Start a fresh session before any plan exists. This step catches the clashing table before it is written.
-
Draft the plan in plan mode
Plan mode lets the agent read the code without changing it. Ask for a plan that reuses what exists and ends with a task list.
-
Execute one task per turn
Each task is small enough to verify and to throw away. When the agent goes wrong on task 7, you lose task 7, not the feature.
-
Check the diff against the chain
Run a review pass that compares what was built with what was accepted: files the plan does not list, and ticked tasks without a test.
-
Merge, then close the loop
The pull request carries the review findings and the test evidence. An incident or a missing requirement becomes the next
intent.md.
The same chain in each tool.
What differs is how you keep the agent read-only while it plans. In all three, the plan only counts once it is a committed plan.md: that file is what CI, review agents and the next session read.
| Tool | Plan mode | Worktree |
|---|---|---|
| Claude Code | Enter plan mode with Shift+Tab, /plan, or claude --permission-mode plan. From v2.1.283 (both release channels on 2026-10-12), interactive terminal and VS Code sessions start in auto mode, so switch to plan mode deliberately. | Run claude -w notifications to work in a new Git worktree, and claude -c to continue the most recent conversation. |
| Codex | Enter plan mode with /plan in the CLI. | Run codex --worktree for a session in a new managed Git worktree (v0.157.1), and codex resume --last to pick up the most recent session. |
| Cursor | Pick Plan in the agent's mode selector. | Worktrees "let Agent work in isolated Git checkouts" (Cursor docs, checked 2026-08-28), which keeps a parallel task off your working branch. |
Recipes by domain.
Each recipe pairs a prompt with the check that proves the output: a failing-first test, a type check, a build or a gate you can run.
Show one domain
Frontend
6 pagesBackend
12 pagesDatabase
5 pagesData
1 pageDevOps
6 pagesMobile
6 pagesError handling
4 pagesA recipe starts by pinning what the agent keeps getting wrong.
Agents learned React from years of React 16–18 code, TanStack Table v8 and Create React App tutorials. Without a pin they reproduce it. The React recipes open with a block for your CLAUDE.md, AGENTS.md or Cursor rule, then check each replacement against the published types.
Excerpt from React Development Recipes, last updated 2026-10-12. The table is the page’s own, headed “Status on 2026-09-26”; 3 of its 6 rows are shown. Open the page (Toolkit)
CLAUDE.md, AGENTS.md or a Cursor rule Show the pin block
## 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 writes | Status on 2026-09-26 | Write instead |
|---|---|---|
useReactTable(options) | Not exported by @tanstack/react-table 9.2.4; only useLegacyTable from /legacy, marked deprecated | useTable({ ...options, features }) with tableFeatures() |
cacheTime in a query | Not in @tanstack/query-core v5 types | gcTime |
z.string().email() | @deprecated Use z.email() instead in Zod 4.6.5 | z.email() |
Go one page further.
Three free pages that sit next to this one.
Questions about the examples.
Something else? Write to support@developertoolkit.ai.
Can’t the agent write these files itself?
It can draft every one. What the chain adds is the order and the sign-off: each file is committed, a named person accepts it, and the next stage reads that file instead of a chat. Without that, the agent makes architectural decisions nobody asked it to make.
Do I need all three files for every change?
A one-file change can go straight to a task. Anything that touches a schema, a public API or more than one layer gets at least spec.md and plan.md, because that is where the clashing-table class of mistake is caught.
Who accepts each file?
The product owner accepts intent.md and spec.md, and a tech lead joins on the spec for higher-risk work. An engineer accepts plan.md for routine work, and a tech lead or architect for higher risk. An agent can draft every file, and a person accepts it.
Do the recipes work in Claude Code, Codex and Cursor?
The cookbook is written for Claude Code, Codex and Cursor. Each recipe pairs a prompt with a check you can run, such as a type check, a test run or a build. Where a file differs by tool, the page says so: CLAUDE.md for Claude Code, AGENTS.md for Codex and a project rule for Cursor.
Can I read any of this before I pay?
The templates and prompts on this page are yours to copy now. The cookbook pages count toward your free articles each month and open in full with the Toolkit. “Start here” and “Autonomy Ladder” are free to read, and the free Level 4 guide covers the four artifacts that exist before a long run starts.
How do I know a recipe is current?
Every page shows when it was last updated. The React recipes list the package versions they were checked against and the APIs agents still write that no longer exist.
Used by engineering teams at
- Grupa Morizon-Gratka
- Ringier Axel Springer
- TasteRay
Creator of wondel.ai Skills — 2.3k+ stars on GitHub (opens in a new tab)
Give the agent a plan it can finish.
Buy the Toolkit and open the full artifact chain guide and 100+ recipes, in English or Polish.
$59.99 once for 12 months of access. Nothing renews on its own. 30-day refund on a first purchase.