Vibe coding prompts: 12 copyable templates for every stage of a build

I want to build [one-sentence description] for [specific user].
Do not write any code yet.
1. Ask me up to five questions that would change how you build it.
2. Then give a plan of at most eight steps, each one small enough to test by itself.
3. List what you would leave out of version one.
Wait for my answers before you start.

Build [name]: a single-page web app.
User: [who], who wants to [one task].
Screen: [the two or three things shown].
Behavior: when the user [action], the app [response]. Example: input [X] gives [Y].
Data: keep it in the browser for now. No login, no server, no database.
Do not build: accounts, payments, settings, or anything not listed above.
Done when: [the exact check you will run].
Afterwards, tell me how to run it and list your assumptions.

Make exactly one change: [what and where].
Do not modify anything else, including [the parts that currently work].
If the change needs touching other files, stop and tell me which and why before editing.
When done, list every file you changed in one line each.

Bug: when I [action] with [exact input], I get [what happened].
Expected: [what should happen, with exact values].
Error text (paste in full, no summary): [error]
Fix only this. Do not change [working parts].
Before editing, tell me in two sentences what you think the cause is.

Explain this project to me as if I have never coded.
1. What does each file do, in one sentence?
2. Where does the data live, and what happens to it when I close the page?
3. Which parts talk to the outside world (servers, other services)?
4. Which two or three parts would be most dangerous to get wrong, and why?
Do not change any code.

Review this project for security problems. Do not change code; report only.
1. List every secret or API key used, where it is stored, and whether it can be seen in the browser.
2. For every database table, say who can read and who can write, and which rule enforces that.
3. List every place user input reaches a database, a file, a page or a command.
4. Rate each finding high, medium or low and say how to test it.
Be specific: file names and line numbers.

Write automated tests for the current behavior of [the calculation / the rules / the form].
Use these cases: [input -> expected output], [input -> expected output], plus empty input, zero and a very large value.
Tests must pass against the code as it is now. If one fails, tell me; that is a bug, not something to hide.
Explain how to run the tests with one command.

Refactor [file or area] to reduce duplication and make it easier to read.
Rules: no behavior changes, no new features, no new dependencies.
Work in steps of one small change. After each step, run the tests and stop if any fail.
At the end, summarize what moved where, in plain language.

Move the [list of items] from browser storage to a hosted database.
Create one table with these columns: [columns and types].
Turn on row-level security. Rules: [who may read, who may write].
The browser may use only the public (publishable) key. The secret key must never appear in front-end code.
Before finishing, show me the table definition and each rule, and give me two test steps to prove another user cannot see my rows.

You are reviewing a change you did not write. Here is the diff: [paste].
Its goal was: [one sentence].
List: (1) anything that does not match the goal, (2) anything that could break existing behavior, (3) anything added that was not asked for, (4) missing tests.
Do not rewrite the code. Report findings, most serious first.

Fresh start on an existing project. Read the code first; change nothing yet.
Goal of the app: [one sentence]. It currently works except for: [the one problem].
Things already tried that did not work: [list].
Find the root cause by reading the relevant code. Explain it in plain English and propose the smallest fix. Wait for my go-ahead before editing.

Write a HANDOFF.md for this project, for a developer who has never seen it.
Include: what the app does; how to run it and test it; the folder structure in a short list; where data is stored; every outside service and key it needs, by name only, never the values; known bugs; decisions we made and why; what to build next.
Keep it under one page. Do not include any secret values.