Home › Rules › Vibe coding prompts

Vibe coding prompts: a cheat sheet of 21 copy-paste prompts for beginners

Built from the prompting guides of Lovable, Bolt, Cursor and Claude Code, checked Oct 20, 2026. Sources below.

• Prompts
• Lovable
• Bolt
• Cursor
• Claude Code

Short answer: the vibe coding prompts that work best are short, one step at a time, and say three things: what you want, what must not change, and how you'll know it worked. Plan before any code, build one feature per message, paste the exact error when something breaks, and ask for a pass/fail check before you launch. Below are 21 prompts sorted by stage, plus a fill-in-the-blanks template. They're plain English, so they work in Lovable, Bolt, Cursor, Claude Code or any other AI coding tool.

The cheat sheet

The vibe coding prompt template

Almost every good prompt below is this template in disguise. Fill in the brackets:

Goal: [what the user can do when this is done]
Context: [the page, file or component; paste errors or screenshots]
Leave alone: [what must not change]
Done when: [a check you can see or run]

• Goal: one thing, said as what the user can do. "Users can reset their password" beats "fix the login".
• Context: name the page or file. Cursor and Claude Code let you type @ to attach a file; in Bolt you can target or lock files in Code view.
• Leave alone: Lovable's guide says to spell out the boundary "even when it feels obvious", and Bolt's says to be explicit about what should and shouldn't change.
• Done when: Anthropic's guide says giving the agent a check it can run (tests, a build, a screenshot) is the difference between a session you watch and one you can walk away from.

1. Plan before any code

1. Interview me first

I want to build [one sentence: what it is and who it's for].
Don't write any code yet.
Interview me first: ask me one question at a time about who uses it, the one key thing they do, what data it saves, and what's NOT in version 1.
Keep going until you understand it, then sum up what you heard in 5 bullet points.

Lovable's prompting guide says asking for clarifying questions up front prevents misunderstandings and wasted effort, and Anthropic's Claude Code guide recommends letting the agent interview you for bigger features. Use it in Plan mode if your tool has one.

2. Turn the answers into a short spec

Turn what we agreed into a file called SPEC.md with:
- The goal in one sentence
- Who it's for
- The pages or screens
- The data we store
- Out of scope for version 1
- A build order of 5 to 8 small steps, each with one line on how I can test it
Don't write any app code yet. Show me SPEC.md and wait for my OK.

A written plan with a test line per step is what keeps every later prompt small. Claude Code's docs suggest starting a fresh session to build from the finished spec.

3. Pick a beginner-friendly stack

I'm a beginner. Suggest the simplest setup for this app: what to build it with, where the data lives, and where it will be hosted.
Give me 2 options at most, in plain English, with what each one costs to start and what would make me outgrow it.
Don't install anything yet.

Asking for two options with the trade-offs stops the agent from quietly picking something you can't maintain. Bolt's docs suggest starting with the app's architecture, including your choice of tools and frameworks.

2. Set up rules once

4. Write my rules file

Read this project and write an AGENTS.md file (under 60 lines) with:
- What the app is, in 2 sentences
- The stack
- The exact commands to run, test and build it
- Rules: work in small steps, explain changes in plain English, ask before changing the database, login or payments, never put secret keys in front-end code
Show it to me before you save it.

A rules file is the prompt you'd otherwise repeat in every chat. Cursor, Codex, Copilot and others read AGENTS.md. Prefer a ready-made one? Use the free rules file generator, or copy from CLAUDE.md examples and Cursor rules examples.

5. Save the look once

Use this design direction for the whole app: [calm and minimal / bold and playful / premium and sleek].
Colors: [your colors]. Font: [font]. Rounded cards, generous spacing.
Reuse existing components before creating new ones.

Lovable's docs recommend picking a style direction early and saving its keywords to Project Knowledge so every new section matches. Bolt has Project Knowledge too.

3. Build one feature at a time

6. Build one step, then stop

Build step [number] from SPEC.md only.
When it's done, stop. Tell me what you changed and exactly how to test it in the preview.

Lovable's and Bolt's docs say the same thing: make one change, check that it works, then move on. It's also the habit that saves the most credits.

7. The feature prompt template

Goal: [what the user can do when this is done]
Where: [the page, file or component]
Leave alone: [what must not change, e.g. login, the header, existing styling]
Done when: [how we'll know it works, e.g. "I can add a habit and it's still there after a refresh"]

The feature version of the template above. Lovable's guide says a good change prompt has three parts: what to build, where it goes, and what must stay untouched.

8. Show me the plan for this change first

Before you change anything, list the files you'll touch and what you'll change in each one, in plain English.
Wait for my OK before editing.

Cheap insurance before any change that touches more than one file. Cursor's and Claude Code's docs both recommend planning first when a change spans several files or you're unsure of the approach.

9. A section with real words

Add a section below the hero: a centered headline "[your real headline]" and three cards in a row. Each card has an icon, a short title and one sentence: [card 1], [card 2], [card 3].
Only change the home page.

Lovable's docs say placeholder text like "lorem ipsum" gives the AI nothing to respond to; real words get the layout sized right. More design prompts: Lovable design prompts.

4. Fix an error

10. Report a bug so it gets fixed the first time

Bug: when I [exact steps], I expect [what should happen] but [what happens instead].
The error message is: [paste it].
Don't change anything yet. Explain the most likely cause in 2 sentences, then suggest the smallest fix.

Expected vs actual plus the exact error lets the AI fix the cause instead of guessing.

11. Fix the cause, not the symptom

The build fails with this error: [paste the error].
Fix the root cause. Don't hide the error, delete a test, or turn off a check to make it pass.
Then run the build again and show me the output.

Anthropic's Claude Code guide uses almost exactly this example: name the error, ask for the root cause, and ask it to prove the build now works.

12. Explain this error like I'm new

Explain this error in plain English: what it means, which file and line it comes from, and the 1 or 2 most likely reasons.
Don't fix it yet.
[paste the error]

Understanding the error first stops the fix-retry loop before it starts.

13. Break the fix-retry loop

We've tried to fix this twice and it's still broken. Stop changing code.
List the 3 most likely causes, most likely first, and how I can check each one.
We'll pick one together before you edit anything.

If this doesn't help, start fresh. Claude Code's docs say that once you've corrected it more than twice on the same issue, a clean session with a better prompt almost always beats a long one; Cursor's docs suggest reverting and refining the plan instead of patching. Use the summary prompt at the bottom of this page to carry over what matters.

5. Check it before you trust it

14. Quick security check

Check this app for these problems and tell me pass or fail for each, with the file and line:
1. Secret keys or passwords in front-end code or committed files
2. Database tables with user data that anyone can read (row-level security off)
3. Pages or API routes that work without logging in but shouldn't
4. Prices or "paid" status that the browser can change
5. File uploads that are public by accident
Don't fix anything until I say which ones to fix.

A short version. The full list, with the one-shot review prompt, is in the vibe coding security checklist.

15. Write and run tests

Write tests for [feature] that cover: the normal case, empty input, and a logged-out user.
Run them and show me the output.
If a test fails, fix the code, not the test.

Giving the agent a check it can run (tests, a build, a screenshot) is the first tip in Anthropic's Claude Code best-practices guide.

16. Review it with fresh eyes

Review the changes since [the last commit / the start of this chat] as if someone else wrote them.
Only flag bugs, security problems, or anything that doesn't match SPEC.md. Skip style nitpicks.
List each problem with the file and a one-line fix.

Claude Code's docs note that a reviewer told to find gaps will usually find some, so telling it to skip style keeps the list to things that matter.

6. Clean up and understand the code

17. Clean up without breaking anything

Clean up [file or folder] without changing what the app does.
First list the changes you'd make (duplicate code, unclear names, very long functions) and why.
Wait for my OK, then make them one at a time and run the app or tests after each.

"Without changing what the app does" and "one at a time" are what make a refactor safe for a beginner. Have a messy project already? The Codebase Fixer Agent kit in the bundle below is built for that.

18. Explain this project to me

Explain this project to me like I'm new to it:
- What each top-level folder is for
- Where the main page, the database code and the login code live
- How to run it
Keep it under 20 lines. Don't change anything.

Claude Code's docs suggest asking the agent the same questions you'd ask a senior engineer when you're new to a codebase.

7. Launch and deploy

19. Pre-launch checklist

Go through this list one item at a time and tell me pass or fail:
1. No secret keys in front-end code or committed .env files
2. Every page has a title and a meta description
3. Forms show a clear error when something goes wrong
4. It works on a phone-sized screen
5. The production build finishes with no errors
Don't fix anything until I say which items to fix.

Pass/fail per item turns "is it ready?" into a short to-do list.

20. Walk me through deploying

I want to put this online on [host]. Walk me through it one step at a time and wait for me to say "done" before the next step.
List every environment variable the app needs, and mark which ones are secret and must never go in front-end code.

One step at a time is just as important for deploying as for building, and the environment variable list is where most first deploys break.

8. Save credits and keep the chat fresh

21. Summarize for a fresh chat

Summarize this project for a new chat in under 200 words:
- What we're building and the stack
- What's done and working
- What's next
- Known bugs and decisions we made
I'll paste this into a fresh conversation.

Long chats get forgetful. Bolt's docs suggest asking for a summary, then resetting the chat history; Claude Code has /clear for the same reason. More ways to spend less: Lovable credits and Bolt tokens explained.

Where to paste them (tool by tool)

Prompts vs rules files

A prompt is one message. A rules file (AGENTS.md, CLAUDE.md, a Cursor .mdc rule, Lovable's Project Knowledge) is sent with every message, so anything you find yourself typing again and again ("explain changes in plain English", "ask before touching the database") belongs there instead. That keeps each prompt short. Start with the free rules library or the generator; to compare formats, see every rules file format.

Prompts that waste time (and credits)

• "Build me an app like Airbnb." Too big for one message. Plan first (prompts 1 and 2), then one step at a time.
• "Make it better." Better how? Lovable's docs suggest words like "replace", "update" or "adjust" plus the exact element.
• "It's broken, fix it." Paste the steps and the error (prompt 10).
• A sixth "still not working". Stop and use prompt 13, or start a fresh chat with prompt 21.

Related

• Lovable prompts that work (17 copy-paste examples)
• Vibe coding security checklist (12 checks before you launch)
• Lovable credits and Bolt tokens explained
• CLAUDE.md examples and best practices
• Cursor rules examples (10 copy-paste .mdc rules)
• Claude Code skills examples (turn a prompt you reuse into a skill)
• Free rules file generator

Sources

• Lovable docs: Prompting best practices
• Bolt docs: Prompt effectively
• Cursor docs: Plan Mode
• Cursor docs: Prompting agents
• Claude Code docs: Best practices
• Lovable docs: Subscription plans
• Bolt docs: Tokens (free plan limits)
• Cursor docs: Rules (AGENTS.md)
• OpenAI Codex docs: AGENTS.md

Checked Oct 20, 2026. These tools change often; if something here no longer matches, tell us at [email protected].