These vibe coding prompts take you from a one-line idea to a shipped app with an AI agent, in five stages: plan, build, fix, polish and ship. The prompts below are built to keep the speed and reduce the risk of shipping code nobody has read. They plan before building, work in small steps, and end with checks.
What is vibe coding?
Vibe coding means building software by describing what you want to an AI agent and letting it write the code. You judge the result by running it, not by reading every line. Andrej Karpathy gave it the name in early 2025, and it has since become a common way to build prototypes, internal tools and small apps. It works surprisingly well for getting something real on screen fast. The risk is that you ship code nobody has read: security holes, leaked keys, data that is lost when something fails, and a codebase that gets harder to change with every fix. For anything that handles other people's data or money, have someone who reads code review what ships.
How to use these prompts
Use them in order for a new project, or jump to the stage you're at. They work in Claude Code, Codex, Cursor and browser-based app builders. Replace the blanks in double braces, or keep the default after the colon.
One rule matters more than any prompt: commit after every step that works. If you use git, ask the agent to commit when a step passes your check. When something breaks later, you can go back to a version that worked instead of digging out of a hole.
Plan
1. One line to spec
Your first prompt on any new project. It turns an idea into something an agent can build, and the questions catch what you hadn't thought about.
I want to build: {{idea}}
Before writing any code, ask me up to {{max_questions:8}} short questions
about who it's for, the main things a user does, what data it stores, and
what's out of scope. Ask them all at once as a numbered list.
After I answer, write a one-page spec: the problem, the users, the core
features (must have vs later), the screens, the data, and what "done" means
for a first version. Keep the first version small enough to build in a day.
2. Pick the stack
If you don't have strong opinions, let the agent choose, but make it explain the choice in plain words and favor boring, well-documented tools.
Based on the spec, recommend a tech stack for the first version. I am
{{experience:not a professional developer}} and I want to deploy on
{{host:Vercel}}.
Prefer popular, well-documented tools over new ones. For each choice
(framework, database, auth, styling), give one line on why. Tell me what
accounts or keys I'll need to create, and what will cost money.
3. Plan the build in milestones
Small milestones are the difference between a working app and a pile of half-finished features.
Break the spec into milestones. Each milestone should:
- Add one thing I can see and try in the browser
- Take no more than an hour or two of your work
- End with a check I can do myself, in plain steps
Number them. Put the riskiest or least certain part early. Save the plan to
{{plan_file:PLAN.md}} so we can both refer to it. Don't start building yet.
4. Project memory file
Agents forget between sessions. A short memory file in the repo tells every new session what the project is and how to work on it.
Create a {{file:CLAUDE.md}} file at the root of this project. Include: what
the app does in two sentences, the stack, how to run it locally, how to run
the tests and the linter, the folder structure, and rules for working here
(small steps, run checks before saying a step is done, never commit secrets).
Keep it under 60 lines. Write it for an AI agent starting a fresh session.
See the guides to CLAUDE.md and AGENTS.md for what else belongs in this file.
Build
5. Build one milestone
Use this for each milestone in turn. The check at the end is yours, not the agent's.
Build milestone {{number:1}} from {{plan_file:PLAN.md}}, and only that.
When you're done:
1. Run the type checker, linter and tests, and fix any errors.
2. Tell me in plain language what you built and which files changed.
3. Give me the exact steps to check it in the browser.
Don't start the next milestone. If something in the plan turns out to be
wrong, stop and tell me instead of working around it.
6. Add a feature to a working app
For changes after the first version. Asking for a plan first stops the agent from rewriting things that already work.
I want to add: {{feature}}
First, tell me in a few bullets how you'll do it, which files you'll touch,
and anything existing that might break. Wait for my "go". Then build it in
the smallest change that works, run the checks, and give me steps to test it
in the browser, including one step that confirms the old behavior still
works.
Fix
7. It broke: fix with the error
When you have an error message. Paste all of it, including the part that looks like noise.
Something broke. Here's what I did and what happened:
What I did: {{steps}}
What I expected: {{expected}}
What happened: {{actual}}
Error (full text from the browser console or terminal):
{{error}}
Find the cause before changing anything. Explain it in plain language, then
make the smallest fix. Don't refactor or touch unrelated code. Tell me how to
confirm it's fixed.
8. Stuck in a loop: reset
When the agent has "fixed" the same bug three times and things are getting worse. A fresh start with a summary beats more patches.
We've tried several fixes and it's still broken. Stop making changes.
Write a short summary for a fresh session: the goal, what's broken, what we
tried and what happened each time, and what you now think the real cause is.
Then tell me which recent changes to undo to get back to the last working
version.
Paste the summary into a new session after you revert. A clean context often solves in one try what a long chat couldn't.
9. Explain what you built
Use it at least once per project. You can't judge code you don't understand at all, and this is the cheapest way to get a working picture.
Explain this app to me as someone who doesn't read code. Cover: the main
parts and what each does, where data is stored, what happens when a user
{{action:signs up}}, and which parts are the most fragile. Use an analogy if
it helps. Keep it under 400 words.
Polish
10. Make the UI look finished
For the moment the app works but looks like a prototype. Specific references give better results than "make it nicer".
Improve the look of {{screen:the main page}} without changing what it does.
Style: {{style:clean and minimal, like Linear}}. Use one accent color:
{{color:#f15a0f}}.
Fix spacing so it's consistent, give text a clear hierarchy (one main
heading, readable body size), align everything to a grid, and add hover and
focus states to anything clickable. Make empty states and loading states look
intentional. Show me before and after descriptions of what changed.
11. Mobile and accessibility pass
Most vibe-coded apps break on a phone. This catches the common problems.
Check every screen at phone width (375 pixels) and fix anything that
overflows, overlaps or is too small to tap. Then check accessibility: every
button and input has a label, color contrast is readable, the whole app works
with the keyboard alone, and images have alt text. List what you fixed and
anything you couldn't.
Ship
12. Pre-ship security check
Run this before anyone else uses the app. It covers the mistakes agents make most often. It does not replace a review by someone who reads code.
Act as a security reviewer and check this app before it goes live. Look for:
- API keys or secrets in the code, in git history or sent to the browser
- Pages or API routes that work without being signed in when they shouldn't
- Users being able to see or change other users' data
- User input that reaches the database, shell or HTML without being checked
- Missing rate limits on sign-in, sign-up and anything that costs money
For each problem: how serious it is, where it is, and the fix. Fix the
serious ones after I say "go".
13. Ship checklist
The last prompt before you share the link.
I'm about to deploy to {{host:Vercel}} and share the app with
{{audience:a few friends}}. Check and tell me, in plain steps:
1. Which environment variables must be set in production, and whether any
are missing.
2. That the production build passes with no errors.
3. What happens when something fails: does the user see a clear message?
4. Whether data is backed up, and what happens if the database is lost.
5. Anything in the app that is still placeholder text or test data.
Make your favorite one a skill
The prompts you run on every project, like the security check and the ship checklist, work better as skills. A skill sits in your agent and runs whenever the task matches, so you don't have to remember it. Paste a prompt into the SKILL.md generator and it becomes a valid SKILL.md that works in Claude Code and Codex. For general advice on working with an agent, read Claude Code best practices.
To keep prompts like these one keystroke away while you build, save them in Kipt: paste to save, press ⌘K to find one, and Enter copies it. Blanks open a small fill-in form, and Kipt remembers what you typed last time, so your host and plan file are already filled in. Your library lives in your own private GitHub repo, and the prompts you promote to skills install with one command.