What should I give Cursor or Claude Code before it writes any code?
Give it the product, not just the feature. An AI coding tool builds exactly what it's given. If it gets one sentence, it fills the rest with defaults. If it gets the page, the architecture and a brief, it builds inside the structure you decided.
The brief is six lines:
STACK: the exact stack (frontend, API, database, vector store, auth) STRUCTURE: folders, services, where tests live AI: retrieval, reviewer step, confidence gate, escalation RULES: typed, env-driven, errors handled and logged, no secrets in code DONE: deploys from main, seeded demo data, a runbook NEVER: mock data on production paths, silent failures
How do I write a build brief for an AI coding tool?
Fill each line with decisions you already made in steps 1 to 4. Nothing new should appear here.
- STACK is the line from step 4, with exact names.
- STRUCTURE names the folders and services, and says where tests live. Tests beside each service keep them visible.
- AI describes the pipeline from step 3: retrieval, the reviewer, the gate and its thresholds, and who gets the escalations.
- RULES are the standards every file follows: typed end to end, config from environment variables, every error handled and logged, no secrets in code.
- DONE is how you'll know the build is finished. It's a check, not an adjective: deploys from main, seeded demo data, a runbook.
- NEVER lists what the code must not do.
Why is the NEVER line the most important?
Because it's the line most people forget. A coding tool trying to make something work will take shortcuts: mock data that ends up on a production path, an exception swallowed so a test passes, a prompt that can send an email without the gate. Say what it must never do before what it should. Then check every NEVER line after every service in step 6.
How does the brief become build prompts?
Give Claude the architecture page and the brief, and ask for one build prompt per service, in build order. Each prompt lists the files to create, the tests to write and the acceptance line from DONE. Cursor or Claude Code then gets the prompts one at a time.
This is what keeps a long build from drifting. Every prompt starts from the same six lines.
Is a six-line brief enough for a real product?
For a small tool, yes. For a real product, the brief sits on top of fuller documents: a product requirements document (PRD) with the build prompts inside it, a design system and a roadmap. Ask Claude to write them from the page and the brief. The six lines stay the summary every prompt is checked against.
What are the common mistakes?
- A brief that is really a wish list. Every line should be a decision, not a hope.
- No NEVER line. You'll find out what it should have said in production.
- DONE as an adjective. "Polished" and "robust" can't be checked. "Deploys from main" can.
- One giant prompt. Split by service. Small prompts are easier to test and review.
- Giving the feature, not the product. The coding tool can't respect a design system or a roadmap it has never seen.
Which templates should I use?
The build brief has the six lines and a filled example from a real build. The Claude Code starter kit puts the same thinking into a one-page CLAUDE.md, with a Never section and a hook that blocks your NEVER list.
What did the brief look like in the real JobFuture build?
Four documents were ready before Cursor opened, written with Claude and with the security-hardening skill switched on: the AI architecture context, the system design, a PRD with seventeen build prompts inside it, and a design system. Plus a roadmap, because version one is the first step, not the product.
The build prompts ran in order. A few of them:
Prompt 0 repository, tooling and rules Prompt 1 backend foundation Prompt 2 authentication and sessions Prompt 5 jobs and worker Prompt 7 personal path and router Prompt 9 frontend and design system Prompt 13 security hardening pass
The build brief
Copy it or download it. No email. Credit: "The Paper-First Method by Sohaib Waheed".