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 · 2026-11-01 · 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.

Keep reading

  • How to Publish an App on Google Play: The Real Play Console Steps — How to publish an app on Google Play: developer account, Create app, store listing, App content forms, the 12-tester closed test and production release.
  • How to Publish an App on the App Store: TestFlight to Approval — How to publish an app on the App Store: Developer Program, App Store Connect, TestFlight, listing, App Privacy, submitting for review and rejections.
  • How to Use Google AI Studio: Playground, Build Mode and Vibe Coding With Gemini — How to use Google AI Studio: test Gemini in the Playground, get an API key, vibe code an app in Build mode, and know when to move to a full-stack builder.
  • Is Vibe Coding Safe? The Real Risks and What to Check Before You Publish — Is vibe coding safe? It can be. The real risks (data leaks, exposed keys, abuse), how to keep secrets safe, and a 30-minute check before you publish.
  • Vibe Coding Examples: 10 Real App Types, Prompts and What Went Wrong — Ten vibe coding examples: the kinds of apps people really build, the first prompt for each, what usually goes wrong and the follow-up prompt that fixes it.
  • Vibe Coding for Beginners: How to Start, Step by Step — A vibe coding tutorial for complete beginners: pick a tool, write a first prompt, test, fix and publish a small app in one afternoon. No coding needed.

Start building free · Templates · Docs

አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)