Vibe Prompt Library
Every prompt we used at the BetaDen Workshop, plus a few more for after.

BetaDen · Kidderminster · 21 May 2026 · Green Gorilla Automation
How to use this library.
These prompts are templates. Square-bracketed bits like [INSERT IDEA] or [BUSINESS TYPE] are placeholders, replace them with your own words before pasting into Replit or Claude. They are not part of the prompt; they are instructions to you.
Each prompt has a one-line "use this when..." above it so you can scan and find the right one fast. You do not need to read this from front to back. Jump to the section you need.
The workflow: prompts in sections 1, 2 and 3 chain together. Start with an idea (Section 1), turn it into a PRD (Section 2), then feed the PRD to Replit (Section 3). Sections 4 onwards are for when something goes wrong or you want to take things further.

Bookmark this. Use it on Monday morning. We update it as we learn.
Three rules before you start.
Straight from Replit's official prompting docs. The whole library follows these.
1
Be specific.
"Build a website" is vague. "Build a portfolio site with Home, About, and Contact sections in a clean modern style" works. The more detail you give, the less the AI has to guess.
2
Plan before you build.
Ask the AI to describe what it is going to do before it does it. Approve the plan, then say go. This one habit saves more time than anything else.
3
One step at a time.
Do not ask for a complete app in one prompt. Ask for the scaffold, then add one feature at a time. Smaller steps = fewer surprises.
Source: docs.replit.com/tutorials/effective-prompting
Section 1 of 8
Section 1
Find an idea worth building.
Before you build anything, make sure the idea is worth your time. Three prompts to find, pressure-test, or sharpen an idea before you spend a single minute in Replit.
Prompt 1.1
Find a pain point worth automating.
Use this when: You know your business has tedious tasks but no specific app idea yet.
I run a [BUSINESS TYPE, e.g. small accountancy practice / online clothing brand / two-vehicle haulage business]. My biggest weekly time-suck is [DESCRIBE THE TASK]. I spend roughly [HOURS] per week on it, and the parts that frustrate me most are [SPECIFIC FRUSTRATIONS, e.g. copying data between systems, chasing the same questions every week, hand-formatting spreadsheets]. Help me think about whether this task could be solved by a small app. Walk me through: 1. What an "ideal" version of this workflow looks like 2. What inputs and outputs the app would need 3. Whether this is a real candidate for a small app, or whether I should just buy an off-the-shelf tool instead 4. If it is a candidate, what the simplest possible first version would be Be honest. If an app is not the right answer, tell me.

The "be honest" at the end is the key. Without it, the AI says yes to everything.
Prompt 1.2
Pressure-test an idea you already have.
Use this when: You have an idea but you are not sure if it is worth building.
I have an idea for a small app: [DESCRIBE THE IDEA IN ONE OR TWO SENTENCES]. Help me pressure-test this idea before I commit time to building it. Specifically: 1. Who exactly would use this and what problem does it solve for them? 2. What is the simplest version that would still be useful? 3. What existing tools already solve this (and why might mine be different)? 4. What could go wrong -- what makes this idea harder than it looks? 5. On a scale of 1-10, how clearly defined is this idea right now, and what is the one thing I should clarify next? Be honest. If the idea has holes, tell me where they are.

Save yourself a wasted weekend. Use this before you commit.
Prompt 1.3
Sharpen a vague idea into a one-sentence problem statement.
Use this when: Your idea is fuzzy and you need to nail it down before writing a PRD.
I want to build something that does [VAGUE DESCRIPTION]. Help me sharpen this. Ask me 5-7 questions to clarify the problem, the user, and what success looks like. After I answer, write me a single-sentence problem statement in this format: "For [SPECIFIC USER], who [SPECIFIC PROBLEM], my app provides [SPECIFIC SOLUTION], unlike [EXISTING ALTERNATIVE]." Then stop. Do not write any code yet.

The "then stop" is doing serious work. It stops the AI sprinting ahead before you are ready.
Section 2 of 8
Section 2
Turn an idea into a PRD.
A PRD is the brief you give Replit. A good PRD means Replit builds what you asked for. A bad PRD means weird inventions and burned credits. Three prompts to write, check, and trim your brief.
Prompt 2.1
Generate a starter PRD.
Use this when: You have a clear idea and want a structured brief Replit can consume.

Plain English: PRD = Product Requirements Document. A short written brief covering what to build, for whom, and how you will know it worked. Think of it as the architect's drawing before the builders arrive.
I want to build a small app. Here is the idea: [INSERT IDEA OR PROBLEM STATEMENT FROM SECTION 1] Write me a product requirements document (PRD) I can give to an AI coding tool like Replit. The PRD must include: 1. One-sentence summary -- what the app does and who it is for 2. Core features (MVP) -- the 3-5 features the app absolutely needs 3. Nice-to-haves (post-MVP) -- features for later, not version 1 4. User flow -- the main path a user takes through the app, step by step 5. Data model -- what gets stored, what the main "things" in the system are 6. Screens / pages -- what views the user sees 7. Success criteria -- how I will know the MVP is working 8. Out of scope -- what the app deliberately does NOT do Keep each section to 3-6 lines. Use plain English. Assume the reader is a junior developer who has never seen my business before.

Read what comes back. Edit anything that does not sound like your idea.
Prompt 2.2
Pressure-test the PRD before building.
Use this when: You have a draft PRD. Before you hand it to Replit, find the gaps.
Here is a draft PRD for a small app I want to build: [PASTE PRD] Review it as if you are a senior product manager. Specifically: 1. What is unclear or ambiguous? Where would a developer have to guess? 2. What is missing? Is there a hidden assumption that needs to be made explicit? 3. What is over-scoped? Which features should be cut from the MVP? 4. What is under-scoped? Is there something fundamental I have not thought of (e.g. login, payments, data export, mobile)? 5. If you had to ask me three questions to sharpen this PRD, what would they be?

Five minutes here saves an hour of fixing later.
Prompt 2.3
Cut a big PRD down to a buildable MVP.
Use this when: Your PRD is too ambitious for the time you have actually got.

Plain English: MVP = Minimum Viable Product. The smallest version of an app that is still useful enough to show someone. Think of it as the version you build to learn, not the version you build to ship forever.
Here is my full PRD: [PASTE PRD] I have [TIME -- e.g. 4 hours / one weekend / two weeks] to build the first version, and I want to show it to [AUDIENCE -- e.g. my business partner, one early customer, my team]. Cut this down to the smallest version that is still useful and demonstrable. For the MVP: - Which features stay? - Which features get deferred to a v2? - What can I fake or hard-code for the first demo (e.g. dummy data, manual processes) rather than actually building? - What is the riskiest assumption I should test first?

If your MVP takes more than a weekend, cut it again.
Section 3 of 8
Section 3
Hand the PRD to Replit and start building.
Four prompts to get from PRD to working app, without burning credits on weird inventions. Follow them in order: scaffold first, mobile second, then features one at a time.
Prompt 3.1
The first build.
Use this when: You have a PRD. You are ready to scaffold the app. This is the most important prompt in the library.
I am building a small app. Here is the PRD: [PASTE PRD] Before you write any code, do this: 1. Plan first. Describe in plain English the tech stack you would recommend, the main pages, the data model, and the order you will build things in. Wait for me to confirm before writing code. 2. Then build the scaffold. Once I confirm, build the basic structure: app skeleton, navigation, empty pages, data model, working database connection. Do not add features yet. 3. Show me the running app and tell me what to test before we add the first feature. Important constraints: - Mobile-friendly from day one (responsive layout, no horizontal scroll) - Use Replit's hosted Postgres database, not in-memory storage - Do not add login or authentication unless my PRD asked for it - Do not add any features beyond what is in the PRD - Keep the styling clean and minimal -- do not spend time on visual polish yet

The "wait for me to confirm" is the key. It stops Replit sprinting ahead with assumptions you did not agree to.
Prompt 3.2
Make it mobile-friendly from day one.
Use this when: After the scaffold is built, make sure the app works on a phone.
Make sure this app works well on a phone. Specifically: 1. All pages should be readable and usable on a 360px-wide screen (typical mobile) 2. Buttons and tap targets should be at least 44px tall 3. Forms should use the right mobile keyboards (email, number, phone) 4. No horizontal scrolling at any width 5. Test the layout at three widths: mobile (360px), tablet (768px), desktop (1280px) Do not redesign anything -- just make the existing layout responsive.

Open your live URL on your actual phone afterwards. If you have to zoom, ask again.
Prompt 3.3
Internal tool with no login needed.
Use this when: The app is just for you and your team. No public users, no need for accounts.
This is an internal tool that only I (and maybe my team of [NUMBER] people) will use. We trust each other. I do not want to spend time on login screens, password resets, or account management. Build the app so it: 1. Skips all login and authentication 2. Has a single "Settings" page where I can paste in any API keys or credentials it needs 3. Uses Replit Secrets for any sensitive values 4. Has no public-facing signup page I will restrict access by keeping the Replit URL private and sharing it only with the people who need it.

Most vibe-coded internal tools never need a login. Do not over-engineer it.
Prompt 3.4
Add one feature without breaking what works.
Use this when: Every time you want to add a new feature to a working app.
The app currently works. Do not change anything that is already there. I want to add ONE new feature: [DESCRIBE THE FEATURE -- e.g. "Let users export the contact list as a CSV file"] Before you change anything, tell me: 1. Which files you will need to edit 2. What new files (if any) you will create 3. What you will add to the database (if anything) 4. How I can test it once you are done Wait for my "go ahead" before writing code. If you spot a problem with my idea, say so first.

Use this prompt every time. Resist the urge to ask for two features in one prompt.
Section 4 of 8
Section 4
Vibe debugging.
When (not if) something breaks. Five prompts, pick the one closest to your situation. You do not need all five; just find the one that matches what you are looking at right now.
Debug 4.1
When something does not do what you expect.
Use this when: The app runs, but it is behaving wrong, not crashing, just not right.
The app is doing [DESCRIBE WHAT IT IS DOING] but I want it to do [DESCRIBE WHAT YOU WANT]. [Optional: paste error message OR describe what you see on screen.] Please fix it without changing anything else.

The phrase "without changing anything else" is the key. It stops the AI rewriting half your app to fix one small thing.
Debug 4.2
When you do not understand the error message.
Use this when: A wall of red text appeared. You have no idea what it means.
I got this error. Please explain what it means in plain English, then fix it: [paste error message exactly as it appeared]

Asking for the explanation first teaches you something. Asking for just the fix does not.
Debug 4.3
When the agent keeps trying the wrong fix.
Use this when: You have asked it to fix the same thing three times. It keeps doing the same thing.
Stop. The last [N] attempts have not worked. Let's start fresh. The behaviour I want is: [describe in plain English]. The current behaviour is: [describe]. Do not change anything else in the app. Walk me through what you think is wrong before you change any code.

Forcing it to explain before acting breaks the loop most of the time.
Debug 4.4
When the app worked yesterday but not today.
Use this when: Nothing changed on your end. Something changed somewhere else.
The app worked yesterday. Today it is broken with this behaviour: [describe]. Please look at the most recent changes and tell me which one likely caused it before you fix anything.

Diagnose before treat. Saves you from making it worse.
Debug 4.5
When you want to undo the last change.
Use this when: That last change made things worse. Go back.
Undo the last change you made and put the app back to how it was before.

Short prompt, big lifesaver. Do not be afraid to use it.
Section 5 of 8
Section 5
Make it look better.
Visual changes work best when you describe the feeling, not the technical detail. Two prompts, one for the overall feel, one for a specific element that is annoying you.
Style 5.1
Change the overall feel.
Use this when: The app works, but it looks wrong for your audience.
Make the app look more [professional / playful / clean / trustworthy / minimal]. Keep the same content and layout, just change the styling.

Pick one adjective at a time. "Professional and playful" confuses everyone, including the AI.
Style 5.2
Change one specific element.
Use this when: One thing on the screen is annoying you and you want to fix just that.
Make the [button / heading / form / menu / card] [bigger / less cluttered / a different colour -- describe in words]. Do not change anything else.

Describe colours in words, not hex codes. "Warmer" or "less aggressive" is better than a long code number.
Section 6 of 8
Section 6
Deploy to a live URL.
Getting it on the internet. Replit usually handles this with a single button, here is the prompt for when the button does not work, or you want to be certain it is done correctly.
Deploy 6.1
Get a live URL.
Use this when: The Deploy button is not working, or you want to be sure the app is properly public.
Deploy this app so I have a public URL I can share. Use the simplest deployment option. Tell me the URL when you are done.

Test the URL in a private browser window. If it loads without logging in, it is properly public.
Deploy 6.2
Point your own domain at the app.
Use this when: You own a domain (yourbusiness.com) and want the app to live there instead of a replit.app address.

Plain English: DNS = Domain Name System. Think of it as the phone book of the internet, it is how typing your domain name finds your actual app. When you set up DNS, you are telling the phone book where your app lives.
I own the domain [yourdomain.com]. Walk me through how to point it at this Replit deployment, step by step. Assume I have never set up DNS before.

Do not change the live app while you do this. DNS can take a few hours to take effect.
Section 7 of 8
Section 7
Plan what to build next.
One prompt to plan a v2 once your v1 is in the wild and people are using it. Do not build v2 until v1 is live and you have heard from at least one real user.
Plan 7.1
Plan a v2 from a working v1.
Use this when: V1 is live. People are using it. You are getting feedback. Now what?
Here is what my app does today: [describe]. Here is what I am hearing from users / what I want next: [describe]. Give me a list of 5 things I could build next, ranked by impact-to-effort. For each, tell me roughly how big a change it is.

Pick one. Build that one. Ignore the others until it is done.
Section 8 of 8
Section 8
Get serious.
When real customers depend on the app and downtime costs you money, this is the prompt for the honest conversation about going production-ready. Most people only need this once, but it is worth knowing it is here.
Production 8.1
The honest conversation.
Use this when: You have gone past the prototype. Real users depend on it. Time to find out what needs to change.
I built this app on Replit using vibe coding. It works but now real users depend on it. I want to understand what needs to change before I trust it with real business data. Please give me a checklist covering: 1. Security and credentials 2. Data backup and recovery 3. Environment separation (dev / staging / production) 4. Monitoring and alerting 5. Tests so future changes do not break what works For each item, tell me what good looks like, what the bad version is, and roughly what it would cost a small business to fix.

If the answer feels overwhelming, that is the moment to talk to a specialist. Green Gorilla Automation runs a structured "Vibe-Code to Production-Ready" service that does exactly this work. greengorillaautomation.co.uk
Find the right prompt fast.
Use this as your index. Scan the Stage column, find where you are, and jump to that section.

Bookmark this slide specifically. It is the index for everything else.
Keep building.
Thanks for spending the morning with us at Betaden. The fact that you are reading this means the workshop did its job.
Paul Rhodes
Green Gorilla Automation
paul@ggapps.co.uk
We update this library as the tools change. The link does not change, bookmark it once and re-scan whenever you need it.

BetaDen · Kidderminster · 21 May 2026 · Green Gorilla Automation