15 Claude Code prompts, one for every stage of a build, Quentin IA Marketing

The problem is not Claude, it is the empty prompt box

You open Claude Code, type three lines, and get back code that compiles but that you do not understand. Two days later you cannot remember why a given file exists.

That is not a model problem. A build has stages, and each stage needs a different instruction.

A good build prompt does not ask for code. It sets constraints and a point where the model has to stop.

Here are the 15 prompts I run, in order. Each one has a precise job, and most of them end with a mandatory pause: the model shows its work and waits.

Claude AI Lab

The Claude AI Lab is my Skool community where I share my Claude systems and the more advanced modules. Access is $67/month.

Join the Lab →

✅How to use them

Replace the brackets. Every prompt has bracketed zones. They are the only thing you change.

Keep the order. The prompts feed each other: the PRD feeds the spec, the spec feeds the implementation plan.

Do not skip the pauses. When a prompt says to wait for your go, that is what saves you from finding a problem 400 lines later.

Frame it

🧭 prompts 1 to 4

Four prompts before writing a line. This is the stage everyone skips, and it is the one that decides everything else.

01. Write a full PRD

Write a complete PRD for the feature below.

Feature: [DESCRIBE FEATURE]
Users: [WHO USES IT]
Stack: [YOUR STACK]

Include:
* Problem statement and success metrics
* User stories with acceptance criteria
* Scope: what ships in v1, what does not
* Data model changes
* Edge cases and failure states
* Open questions for me to answer

Keep it under two pages. Be specific, no filler. Save it as
docs/prd-[feature].md so every later prompt can point at it.

02. Create your CLAUDE.md

Read this entire codebase, then write a CLAUDE.md.

Include:
* What this project is, in two lines
* Tech stack and the versions that matter
* Commands: [DEV / BUILD / TEST / LINT]
* Architecture: where things live and why
* Code conventions you actually detect in the code
* Hard rules: [YOUR NON-NEGOTIABLES], what never gets touched
  without asking
* Gotchas a new engineer would hit in week one

Write rules as short imperatives. Nothing generic, only what is true
for THIS repo. When you are unsure about a rule, ask me instead of
inventing it.

03. Ultra plan mode

Enter plan mode. Do NOT write any code yet.

Task: [PASTE TASK]
Constraints: [DEADLINE / STACK / NO-GO ZONES]

1. Read every file this task touches, list them with one line on what
   each does today
2. Map current behavior against target behavior
3. Propose two or three approaches with real tradeoffs: complexity,
   risk, blast radius
4. Pick one and justify it in three lines
5. Break it into steps small enough to verify one at a time, each with
   its own check
6. List the risks and the exact rollback for each
7. Flag anything touching [AUTH / PAYMENTS / PROD DATA] for my explicit
   sign off

Then stop. Show me the plan and wait for my approval before touching a
single file.

04. Spec driven development

We build specs first. Write a spec for: [FEATURE]

Context: [WHO USES IT + WHY NOW]

Spec format:
* Behavior: given, when, then, every case, happy path, edge cases,
  failure states
* API contract: inputs, outputs, error shapes, status codes
* Data: schema changes and migrations needed
* UI states: loading, empty, error, success
* Non goals: what this spec deliberately skips
* Acceptance checklist I can verify line by line

Once I approve the spec, implement EXACTLY the spec. When reality forces
a deviation, stop, update the spec, get my go, then continue. The spec
is the source of truth, not the code.

The real payoff

These four prompts take twenty minutes. They save you the two days you would spend undoing a build that went the wrong way.

Design it

🎨 prompts 5 and 6

05. Full UI and UX design brief

Create a full UI and UX design brief for: [SCREEN OR FLOW]

Audience: [USERS]
Brand: [COLORS / FONTS / VIBE]

Deliver:
* User journey through the flow, step by step
* Layout per screen: hierarchy, spacing, breakpoints
* Component inventory with every state: hover, empty, error, loading
* Typography and color tokens
* Motion: what animates, duration, easing
* Accessibility notes

Study patterns from [2-3 PRODUCTS YOU ADMIRE] for direction. Never copy
them.

06. Implementation plan

Create an implementation plan for: [APPROVED SPEC / PRD]

Rules:
* Sequence steps so the app compiles and runs after EVERY single step
* Each step: files touched, what changes, how I verify it works
* Flag steps needing a migration or a new dependency
* Put the riskiest unknowns first
* Size each step: [S / M / L]

Output a numbered build sequence I can run one step at a time. Wait for
my go between steps.

Wire it

🔌 prompts 7 and 8

07. Wire up an MCP server

Wire up an MCP server for: [SERVICE / API]

What I need it to do: [JOBS TO BE DONE]

1. Check for an official or well maintained server first, and name your
   source
2. When one exists: exact install command plus the .mcp.json config,
   scoped to this project
3. When none exists: scaffold one with the MCP SDK. Tools, auth, error
   handling, typed responses
4. Add ONLY the tools I will actually use: [LIST]
5. Wire secrets through [ENV VARS], never hardcode keys in the config file
6. Verify the connection and call one tool end to end, show me the output
7. Document each tool in one line so future sessions know when to reach
   for it

08. Connect your database

Connect this app to [POSTGRES / SUPABASE / YOUR DB].

* Pick the client that fits this stack, justify it in one line
* Env vars: name them, add to .env.example, never commit real values
* Schema: tables for [ENTITIES] with types, relations, and indexes for
  [HOT QUERIES]
* Create and run the migrations, and show me the rollback for each one
* One typed query helper per table, no raw SQL scattered through
  components
* Access rules and row level security when this is [MULTI-TENANT]
* Connection pooling when we are serverless

Then prove it: seed one row, read it back, show me the output.

Harden it

🛡️ prompts 9 to 11

09. Find security gaps

Audit this codebase for security gaps. Attack it like you want in.

Focus areas: [AUTH / PAYMENTS / USER DATA]

Check:
* Secrets in code, config, or git history
* Injection: SQL, XSS, command, path traversal
* Auth: routes missing checks, weak sessions, broken redirects
* IDOR: can user A read user B data?
* File uploads and input validation on every form
* Dependency CVEs, run the audit and read it
* Rate limiting on [EXPENSIVE ENDPOINTS]
* What leaks through error messages and logs

Rank findings by severity with exact file and line, fix the critical
ones now, and list the rest as tickets with effort estimates.

10. Debug an error fast

Debug this error. Do NOT guess.

Error: [PASTE FULL ERROR + STACK TRACE]
When it happens: [STEPS TO REPRODUCE]

1. Read the stack trace, open the exact files involved
2. State expected against actual behavior in one line
3. List three hypotheses, ranked by likelihood
4. Prove or kill each one with logs or a tiny test. Evidence, not vibes
5. Fix the root cause, not the symptom
6. Search the repo for the same pattern. When it can break here, it
   breaks elsewhere
7. Add a regression test that fails without the fix
8. Tell me in two lines why it broke and why it can never break this
   way again

11. E2E test your application

Write Playwright E2E tests for: [FLOW]

Stack: [YOUR STACK]   CI: [GITHUB ACTIONS / OTHER]

* Money paths first: [SIGNUP / CHECKOUT / CORE ACTION]
* Test what the user sees, not implementation details
* Selectors: roles and labels, never brittle CSS chains
* One unhappy path per flow: bad input, network failure, expired session
* Tests stay independent: any order, zero shared state, each seeds its
  own data
* Headless in CI, headed locally for debugging
* Screenshots and traces on failure only

Run the suite, show me the results, fix what fails, and tell me what the
suite still does NOT cover.

Finish it

🧹 prompts 12 to 15

This is the stage almost nobody does, and it is what separates a project you can pick up six months later from one you rewrite.

12. Clean up dead code

Find and delete dead code in this repo.

Scope: [WHOLE REPO / SPECIFIC FOLDER]

* Unused exports, components, hooks, utils
* Unreachable branches and commented out blocks
* package.json dependencies nothing imports
* Stale feature flags stuck always on or always off
* Duplicate logic that should merge into one
* Dead CSS classes and unused assets

Verify with a search before EVERY deletion: dynamic imports and string
references count. Delete in small commits, run [BUILD + TESTS] after
each one, and report total lines removed plus anything you were not
fully sure about.

13. Write clean git commits

Commit my staged changes properly.

Convention: [CONVENTIONAL COMMITS / YOUR FORMAT]

* Split unrelated changes into separate commits
* Format: type(scope): what changed and why.
  feat, fix, refactor, chore, docs, test
* Subject under 50 characters, imperative mood
* Body explains the WHY, wrapped at 72
* Reference the ticket: [TICKET-ID]
* Never mix a refactor with a behavior change in one commit
* Never commit [SECRETS / .ENV / GENERATED FILES]

Show me the plan, files per commit plus messages, before you commit
anything. Then commit one at a time so I can stop you between them.

14. Hooks as guardrails

Set up Claude Code hooks as guardrails here.

Stack: [YOUR STACK + PACKAGE MANAGER]

* PostToolUse: run [LINT + TYPECHECK] after every file edit, feed errors
  straight back
* PreToolUse: block edits to [PROTECTED PATHS: MIGRATIONS, .ENV,
  PROD CONFIG]
* Stop: run [TEST SUITE] before a session ends
* Notification: ping me with [SOUND / SLACK] when my input is needed

Write the hook scripts plus the settings.json entries. Keep each script
under 20 lines and exit non zero with a clear message so the agent knows
exactly what to fix. Then trigger each hook on purpose and show me it
firing.

15. Turn a task into a skill

Turn this repetitive task into a Claude Code skill.

The task I keep doing: [DESCRIBE TASK + STEPS]

* Create .claude/skills/[NAME]/SKILL.md
* Frontmatter: name plus description with the exact trigger phrases I
  actually say
* Body: numbered workflow, my conventions, edge cases
* What it should ask me for against what it infers on its own
* What "done" looks like

Then dry run the skill on a real example and refine until the output
matches how I do it by hand.

The one that matters most

Number 15. A build always produces tasks you will redo. Every time you turn one into a skill, you never do it by hand again.

What makes these different from "code this for me"

Three things show up in almost all of them, and they do the actual work.

🛑

A mandatory pause

Half of these prompts end with a stop. The model shows its plan and waits. That is what lets you correct direction before 400 lines exist.

📐

A constraint, not a wish

"Under 50 characters", "two pages maximum", "under 20 lines". A precise number produces a precise result, an adjective produces nothing.

🔍

Proof on demand

"Show me the output", "prove it". Without that, the model tells you it works without having checked.

Start with number 02, the CLAUDE.md one. It is the only prompt every other one benefits from, because it gives the model the context you otherwise re-explain every session.