15 Vibe Coding Prompts for Claude Code: Every Stage of Building an App

promptBefore we build anything, pressure-test this app idea: [describe your idea in 2 or 3 sentences].

Tell me:
1. Who exactly is it for, and what are they doing today instead?
2. The one problem it solves, in a single sentence.
3. The smallest version that would still be useful to that person. List the 3 to 5 features it needs and nothing else.
4. The 3 biggest risks: technical, "nobody wants this", and anything that needs payments, logins or personal data.
5. What I can cut from my idea without losing the point.

Be blunt. If the idea is too big for a first version, say so and propose a smaller one. Don't write any code.

promptI want to build [the smallest version from the last step]. Interview me in detail using the AskUserQuestion tool.

Ask about who uses it, every screen, what the user can do on each one, the data we store, logins and permissions, edge cases, empty and error states, and what is out of scope. Don't ask obvious questions. Dig into the hard parts I haven't thought about.

Keep interviewing until we've covered everything, then write SPEC.md with:
- One-paragraph summary and target user
- User stories ("As a ... I can ... so that ...")
- Features for v1, and an explicit "Not in v1" list
- Screens and what each one shows
- Data model: every table or collection, its fields, and how they relate
- Edge cases and error states
- Acceptance criteria for each feature, written so they can be tested
- A final end-to-end check that proves v1 works

Don't write any code.

promptRead SPEC.md and recommend a tech stack for v1.

Rules:
- Choose the simplest stack that can ship this spec. Prefer tools with big communities and good docs, since you'll be writing most of the code.
- For each piece (frontend, backend, database, auth, hosting, payments if needed), give your pick, one runner-up, and why.
- Flag anything that costs money, the free tier limits, and anything that locks me in.
- List every account or API key I'll need to create, and what each one is for.

Add a "Stack" section to SPEC.md with the final choices. Ask me before adding any paid service.

promptRun /init if this project has no CLAUDE.md yet. Then rewrite CLAUDE.md using SPEC.md and the stack we picked.

Include only what you can't figure out from the code:
- What the app is, in two lines, and a pointer: "Full spec: @SPEC.md"
- The exact commands to install, run, test, lint, type check and build
- Folder structure: where pages, components, API routes, database code and tests live
- Code style rules that differ from the defaults
- Workflow rules: run the checks after every change, never commit secrets, ask before adding a dependency, ask before deleting files
- Known gotchas (environment variables, ports, anything that broke before)

Keep it under 200 lines. For every line, ask: would removing this cause you to make a mistake? If not, cut it. Show me the file before you save it.

promptSet up the project from SPEC.md and CLAUDE.md:
1. Create the project with the stack we chose, and install only what v1 needs.
2. Add scripts for dev, build, lint, type check and test.
3. Write one tiny passing test so the test runner is proven to work.
4. Create .env.example with every variable the app needs (placeholder values only) and make sure .env is in .gitignore.
5. Start the dev server and confirm the app loads.
6. Run build, lint, type check and test, and paste me the output of each.
7. Initialize git and make the first commit.

Stop if any check fails and fix it before moving on. Update the commands in CLAUDE.md if any of them changed.

promptDon't write code yet. Read SPEC.md and CLAUDE.md and explore the project, then write PLAN.md.

Break v1 into phases that each end in something I can click and test. For every phase list:
- The goal, in one sentence
- The files you'll create or change
- The steps, in order
- The tests you'll add and the exact command that proves the phase works
- Risks and open questions

Order the phases so the riskiest part gets built first. Keep each phase small enough to finish in one session. Ask me about anything in the spec that is unclear before you finalize the plan.

promptImplement Phase [N] from PLAN.md and nothing else.

- Follow the patterns already in the codebase and the rules in CLAUDE.md.
- Write the tests listed for this phase, then make them pass.
- Run lint, type check, test and build. If something fails, fix the root cause. Never skip, disable or delete a test to get green.
- When you're done, show me the command output as evidence, list every file you changed, and tell me how to try the feature in the browser.
- Tick the phase off in PLAN.md and note anything you learned.

Stop after this phase. Don't start the next one.

promptBuild the [screen name] screen from SPEC.md. Here is my reference: [paste a screenshot, a sketch, or a description of a site whose style you like].

- Match the layout, spacing and visual hierarchy of the reference. Use our own content and our own brand colors and fonts: [list them, or ask me].
- Make it work at phone width (375px) and desktop width (1440px).
- Include the loading, empty and error states from the spec.
- Use real labels and sample data that looks real. No lorem ipsum.
- If you can take a screenshot of the result, compare it to the reference and fix the differences. If you can't, give me a short checklist of what to look at in the browser.

promptBuild the data layer and API for [feature] from SPEC.md.

- Create the tables or collections from the data model, with a migration if our stack uses them.
- For every endpoint: validate every input on the server, check that the user is logged in AND allowed to touch that specific record, and return clear error messages.
- Never trust anything sent from the browser, including prices, user IDs and roles.
- Handle the empty, not found and duplicate cases.
- Add tests for the happy path, bad input, and a user trying to read or change someone else's data.
- Run the tests and show me the output.

promptLook at what we've built so far and find the code paths with no tests.

1. List the 10 most important untested behaviors, ranked by how bad it would be if they broke (money, data loss, security, login first).
2. Write tests for the top 5. Cover edge cases: empty input, very long input, special characters, double submits, expired sessions.
3. Prefer real behavior over mocks. Only mock outside services like payments or email.
4. Run the full suite and show me the output.

If a new test exposes a bug, don't fix it yet. Write the test so it fails, show me the failure, and explain the bug.

promptUse a subagent to review the current changes against SPEC.md and PLAN.md, so the reviewer isn't the one who wrote the code.

The reviewer should check:
- Every acceptance criterion in the spec is implemented and has a test
- Nothing outside the current phase changed
- Bugs, race conditions and unhandled errors
- Code that duplicates something that already exists in the project

Report only gaps that affect correctness or the stated requirements, with file and line. Skip style preferences. Then fix the real gaps and run the checks again.

promptAct as a security reviewer. Audit this whole app for security gaps. Don't change any code yet.

Check for:
1. Secrets: API keys, tokens or passwords in the code, git history, frontend bundle or logs. Confirm .env is gitignored.
2. Authentication: every page and API route that should need a login actually checks for one, on the server.
3. Authorization: a logged-in user can't read, change or delete another user's data by changing an ID in the URL or the request.
4. Input: SQL or NoSQL injection, XSS, unsafe file uploads, and redirects to any URL.
5. Paid API keys: any endpoint that calls a paid API (AI models, email, SMS, payments) needs authentication, a locked origin allowlist (never CORS *), rate limiting, and hard caps on model and max tokens, or anyone who finds the URL can run up your bill.
6. Rate limiting on login, signup, password reset and any form that sends email.
7. Dependencies: run the package manager's audit command and list known vulnerabilities.
8. Errors and logs: no stack traces shown to users, no passwords or personal data in logs.

For each finding give severity (critical, high, medium, low), the file and line, how someone could exploit it, and the fix. Sort by severity. Wait for my approval before fixing anything.

promptThere's a bug: [what you expected] vs [what actually happens]. Steps to reproduce: [steps]. Error message, if any: [paste it].

Debug it with evidence, not guesses:
1. Reproduce it first, and show me the exact command or steps and the output.
2. Read the relevant logs, error output and code paths before you change anything.
3. List up to 3 possible causes, ranked, with the evidence for and against each one.
4. Add temporary logging or a failing test to prove which cause is real.
5. Fix the root cause, not the symptom. Don't suppress the error, wrap it in a try/catch that hides it, or delete the check that catches it.
6. Run the failing test and the full suite, and show me both outputs.
7. Remove the temporary logging and tell me in two sentences what was wrong and why the fix works.

If you've tried two fixes and neither worked, stop and tell me what you've learned instead of trying a third.

promptWe're about to launch v1. Run a pre-launch check and give me a pass or fail list:

- Build, lint, type check and the full test suite all pass (show the output)
- Every acceptance criterion in SPEC.md works end to end
- Every environment variable the app needs is listed in .env.example and documented
- Error pages and empty states exist and look finished
- Page titles, descriptions and a favicon are set
- Forms work on a phone, and buttons have labels a screen reader can read
- No console errors or warnings on the main pages
- The security findings from the audit are fixed, or written down as accepted risks
- README explains how to install, run and deploy

Fix the small failures. List the big ones for me to decide on. Then write the exact deploy steps for our host, and wait for my go before running anything that deploys.

promptWe're stopping for today. Update the project so the next session can pick up without me explaining anything:

1. In PLAN.md, mark what's done, what's in progress and what's next.
2. Write PROGRESS.md: what we did this session, decisions we made and why, known bugs, and the very next step as a ready-to-paste prompt.
3. Add anything new you learned about this project to CLAUDE.md (new commands, gotchas, rules), and keep it under 200 lines.
4. Commit everything with a clear message.

Then tell me the one prompt I should paste to start next time.