15 Vibe Coding Prompts for Claude
Vibe coding is not sloppy when your prompts are specific. Copy these 15 and put structure, checks, and guardrails around every stage of a build.
Vibe coding is not about asking Claude to "build an app" and hoping for the best. The people who ship real software this way write prompts that set the scope, name the constraints, and say exactly what "done" looks like.
The 15 prompts below follow a build from first idea to shipped feature. Each one tells Claude what to produce, what rules to respect, and when to stop and wait for you.
How to use them: tap Copy prompt, paste it into Claude, then replace every highlighted placeholder like [YOUR STACK] with your own details before you send.
Plan before you build
Prompts 1 to 6 turn a vague idea into approved documents. Nothing gets coded until you have signed off on what you are building.
Write a Full PRD
Gives every later prompt a written source of truth to point back to.
Feature: [DESCRIBE FEATURE]
Users: [WHO USES IT]
Stack: [YOUR STACK]
Include:
* Problem statement + success metrics
* User stories with acceptance criteria
* Scope: what ships in v1, what does not
* Data model changes
* Edge cases + failure states
* Open questions for me to answer
Keep it under 2 pages. Be specific, no filler.
Save it as docs/prd-[feature].md so every later
prompt can reference it.
Create Your CLAUDE.md
Claude reads this file at the start of a session, so it stops guessing your conventions.
Include:
* What this project is, in 2 lines
* Tech stack + 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 to
never touch without asking
* Gotchas a new engineer would hit in week 1
Write rules as short imperatives. Nothing generic --
only what is true for THIS repo. If you are unsure
about a rule, ask me instead of inventing it.
Ultra Plan Mode
Forces the thinking to happen before a single file changes.
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 vs target behavior
3. Propose 2-3 approaches with real tradeoffs:
complexity, risk, blast radius
4. Pick one and justify it in 3 lines
5. Break it into steps small enough to verify
one at a time, each with its own check
6. List risks + 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.
Spec-Driven Development
Makes the spec, not the code, the thing you approve and verify.
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 + migrations needed
* UI states: loading, empty, error, success
* Non-goals: what this spec deliberately skips
* Acceptance checklist I can verify line by line
After I approve the spec, implement EXACTLY the
spec. If reality forces a deviation, stop, update
the spec, get my ok, then continue. The spec is
the source of truth, not the code.
Full UI & UX Design Brief
Covers every state of every component, not just the happy-path screen.
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 + color tokens
* Motion: what animates, duration, easing
* Accessibility notes
Study patterns from [2-3 PRODUCTS YOU ADMIRE]
for direction. Never copy them.
Implementation Plan
Keeps the app compiling and running after every single step.
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 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.
Connect your tools and data
Prompts 7 and 8 give Claude real access to services and your database, with secrets kept out of the code.
Wire Up an MCP Server
Prefers an existing server, and keeps secrets out of the config file.
What I need it to do: [JOBS TO BE DONE]
1. Check for an official or well-maintained
existing server first -- name your source
2. If one exists: exact install command + the
.mcp.json config, scoped to this project
3. If not: 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 1 line so future
sessions know when to reach for it
Connect Your Database
Migrations with rollbacks, and one typed query helper per table.
* Pick the client that fits this stack,
justify it in 1 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 + 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 / row-level security if this
is [MULTI-TENANT]
* Connection pooling if we are serverless
Then prove it: seed one row, read it back,
show me the output.
Test, debug and harden
Prompts 9 to 12 are your quality gate: attack the code, chase bugs with evidence, test the money paths, and delete what is dead.
Find Security Gaps
Tells Claude to attack the code, then rank what it finds by severity.
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's data?
* File uploads + input validation on every form
* Dependency CVEs -- run the audit, read it
* Rate limiting on [EXPENSIVE ENDPOINTS]
* What leaks through error messages and logs
Rank findings by severity with exact file:line,
fix the critical ones now, and list the rest
as tickets with effort estimates.
Debug an Error Fast
Evidence over guessing: ranked hypotheses, each proven or killed.
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 vs actual behavior in 1 line
3. List 3 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 -- if
it can break here, it breaks elsewhere
7. Add a regression test that fails without
the fix
8. Tell me in 2 lines why it broke and why it
can never break this way again
E2E Test Your Application
Money paths first, and every test stays independent of the others.
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 + traces on failure only
Run the suite, show me the results, fix what
fails, and tell me what the suite still does
NOT cover.
Clean Up Dead Code
Every deletion is verified by a search first, then committed small.
Scope: [WHOLE REPO / SPECIFIC FOLDER]
* Unused exports, components, hooks, utils
* Unreachable branches + 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 100% sure about.
Ship and automate
Prompts 13 to 15 keep history clean, enforce your rules automatically, and capture repeated work as a skill.
Write Clean Git Commits
Claude shows the commit plan first, then commits one at a time.
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 chars, 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 + messages --
before you commit anything. Then commit one at
a time so I can stop you between them.
Hooks as Guardrails
Lint, tests, and protected paths enforced automatically, not by memory.
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 + 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.
Turn a Task Into a Skill
Turns work you repeat into a reusable skill, then dry-runs it.
The task I keep doing: [DESCRIBE TASK + STEPS]
* Create .claude/skills/[NAME]/SKILL.md
* Frontmatter: name + description with the exact
trigger phrases I actually say
* Body: numbered workflow, my conventions,
edge cases
* What it should ask me for vs infer 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.
Make the prompts yours
These work best as a system, not a menu. Start with the PRD and CLAUDE.md, plan before you code, and let hooks and tests enforce the rules. Save the ones you reuse as skills, and your next build starts from a much better place.