Guides / Prompting and shipping
30 Vibe Coding Prompts You Can Copy (Cheat Sheet)
30 vibe coding prompts you can copy and paste, grouped by stage: first build, planning, design, data, fixing bugs, testing, security and publishing.
Mythex Team · · 7 min read
The best vibe coding prompts are short, specific and about behaviour: who uses the app, what they can do, what it keeps, and how it looks. Below are 30 prompts you can copy and paste, grouped by the stage you're at, from the first build to publishing. Replace the parts in [brackets] with your own details.
They work in any AI app builder or coding agent. If you want the reasoning behind them, our longer guide on how to write prompts for AI app builders explains the principles. This page is the cheat sheet.
How to use this cheat sheet
- Start with one first-build prompt, then use the others one at a time.
- Test after every prompt. Click through the change before sending the next one.
- Keep what works. Most follow-up prompts here end with "keep everything else the same" for a reason.
- Paste exact text. Error messages, button labels and the words on screen beat descriptions every time.
First-build prompts
These set the shape of the app. Each one names the users, the actions, the data and the look.
1. A simple tracker
Build a [habit] tracker for me. I can add a [habit] with a name and a colour, tick it off once per day, and see a 30-day grid and my current streak. Save everything so it's still there after a refresh. Clean, minimal design that works on a phone.
2. A small business booking page
Build a booking page for my [hair salon]. Customers pick a service ([cut 30 min, colour 90 min]), a date and a free time slot between [9:00 and 18:00], then enter name, phone and email. Two people can't book the same slot. I need a private admin page, behind a login, that lists upcoming bookings by day.
3. An internal tool
Build an internal tool for my team to track [equipment loans]. Each item has a name, a code and a status (available, on loan, broken). Staff log in, can check an item out to themselves and check it back in. Show a table with filters by status and a history of who had each item.
4. A landing page with a waitlist
Build a one-page website for [my product: a meal-planning app for busy parents]. Hero with headline, one-sentence subheading and an email sign-up. Then three benefits, a short how-it-works section and an FAQ. Save sign-up emails to a database and show me the list on a private admin page.
5. A client portal
Build a client portal for my [design studio]. Each client logs in and sees only their own projects, with status, files I've uploaded and a comment thread. I log in as admin and see all clients. Clients must never see each other's data.
6. A calculator or quote tool
Build a quote calculator for my [cleaning business]. Inputs: number of bedrooms, bathrooms, extra services (oven, windows, fridge) and frequency (one-off, weekly, monthly). Show the price as the options change, with a breakdown. Prices: [paste your price list]. Add a button to send the quote request to me by email.
Planning prompts
Use these before a big feature, or whenever you're not sure how to describe something.
7. Plan before building
Before you write any code, describe in plain words the screens you'll build, the data you'll store and any decisions you need from me. Wait for my OK.
8. Turn a messy idea into a first version
Here's my idea: [paste notes]. Suggest the smallest first version that's still useful, in 5–8 bullet points. List what you'd leave for later and why.
9. Ask what's missing
What questions would a developer ask me before building this? Ask them one by one, then summarise my answers as a short spec.
10. Check a big change first
I want to add [team accounts where several people share one workspace]. Explain what has to change in the data, the screens and the permissions, and what could break. Don't change anything yet.
Design prompts
11. Set a clear style
Restyle the app: warm off-white background, dark text, one accent colour [#1F6F50], rounded corners, generous spacing and a modern sans-serif font. Keep the layout and every feature exactly as they are.
12. Copy the feel of a reference
Make the dashboard feel like a calm finance app: lots of white space, numbers large and bold, labels small and grey, one simple chart at the top. Don't copy any brand's logo or text.
13. Fix the phone layout
On a phone 375px wide, the table on [the Orders page] scrolls sideways and the buttons overlap. Turn each row into a stacked card on small screens. Don't change the desktop layout.
14. Empty, loading and error states
Add proper states to [the Projects list]: a friendly empty state with a button to add the first project, a loading skeleton while data loads, and a clear message with a retry button if loading fails.
15. Right-to-left support
Add an Arabic version of the interface with full right-to-left layout. Icons that point a direction should flip; numbers and dates should use the locale format. Keep English as the default.
Data and feature prompts
16. Make data persist
Right now my data disappears when I refresh. Store it in a real database instead, and keep the current screens working the same way.
17. Add login
Add sign-up and login with email and password. Each user should only see and edit their own [entries]. Show the user's email in the top bar with a log-out button.
18. Add roles
Add two roles: admin and member. Admins can add, edit and delete [products]; members can only view them. Enforce this on the server, not just by hiding buttons.
19. Add search and filters
Add a search box above [the contacts list] that matches name, company or email as I type, plus a filter for [status]. Keep the current sort order.
20. Add file uploads
Let users attach up to [5] images to each [listing], max [5 MB] each. Show thumbnails on the listing and a larger view on click. Only the owner can delete their images.
21. Import from a spreadsheet
Add an Import button that takes a CSV with columns [name, email, phone, notes], shows a preview of the first 10 rows and lets me confirm before saving. Skip rows without an email and tell me how many were skipped.
Fixing prompts
22. Report a bug clearly
When I [click Save on the edit form], I see "[exact error text]" and the change isn't saved. Expected: the change saves and I return to the list. Find the cause, explain it in one or two sentences, then fix it.
23. Stop a fix loop
We've tried to fix this three times and it still fails. Stop changing code. List the three most likely causes, how to check each one, and which you think it is.
24. Undo side effects
Your last change fixed the date picker but the [sidebar] disappeared. Bring the sidebar back exactly as it was and keep the date picker fix.
25. Explain before you change
Explain how [the checkout total] is calculated right now, step by step, pointing to the files involved. Don't change anything.
Testing and review prompts
26. Edge cases
List 10 ways a real user could break [the booking form]: empty fields, very long text, double clicks, two people at once, wrong time zones. Test each one and fix what fails. Report what you changed.
27. Summarise recent changes
Summarise every change you made in the last [five] steps in plain words, and flag anything that could affect existing data.
Security prompts
Pair these with our page on whether vibe coding is safe.
28. Check data access
Check the server code: can a logged-in user read or change another user's [records] by changing an ID in a request? Show me where access is checked and fix any gaps.
29. Check for exposed secrets
List every API key, password or token this app uses and where each one is stored. Make sure none of them are in code that runs in the browser or committed in files. Move them to secrets if they are.
Publishing prompts
30. Pre-launch pass
I'm about to publish this for real users. Go through it as a reviewer: broken links, missing page titles and descriptions, forms without validation, slow pages, console errors and anything that looks unfinished on a phone. Give me a list ordered by importance, then fix the top five.
Prompts to avoid
Some prompts reliably produce worse results:
- "Make it better." Better how? Name the screen and the change.
- "Fix everything." The AI will change a lot and you won't know what moved.
- "Use [library] and [framework] and [pattern]." Unless you have a reason, describe the behaviour and let the tool choose the stack.
- "Here's my API key: …" Never paste secrets into a chat. Use the tool's secret settings.
- Ten features in one message. Split them up.
Turning prompts into a habit
After a few projects you'll have your own versions of these. Keep them in a note, and reuse the ones that work. Mythex also remembers who you are and how you work across projects, so preferences you repeat, such as your usual style or stack, carry over without retyping them.
If you're stuck on a first prompt, the free app prompt generator turns a one-line idea into a fuller starting prompt. And to see what these prompts produce in practice, read our vibe coding examples, or paste prompt 1 into the AI app builder and change the brackets to your own idea.
Questions
What makes a good vibe coding prompt?
It says who the app is for, what someone can do in it, what data it keeps and how it should look, in a short paragraph. After the first build, good prompts ask for one change at a time and say what to keep the same.
Should I write one long prompt or many short ones?
Use one solid paragraph for the first build, then short prompts for each change. Very long first prompts with dozens of features tend to produce something half-finished everywhere, while small follow-ups are easy to test and undo.
Do these prompts work in any vibe coding tool?
Yes. They are written in plain language for any AI app builder or coding agent, including Mythex, Lovable, Bolt, Replit, Cursor and Claude Code. Tools that don't host apps will need you to handle running and publishing yourself.
Can I write vibe coding prompts in my own language?
Usually, yes. Most modern models understand many languages. Mythex accepts prompts in any language and its interface comes in 64, and it handles Arabic and other right-to-left layouts.
How do I stop the AI from changing things I didn't ask for?
Say it directly: name the part to change and add a line such as "don't change anything else." Keep changes small so you can see what moved, and use checkpoints or undo when a change goes too far.