Vibe Coding — Prompt Library

How to Use This Library

Copy. Fill. Send.

1

Find your situation

Use the category filter above or scroll to find the prompt that matches what you're trying to do right now. Each prompt has a "When to use" note to help you choose.

2

Copy and fill brackets

Hit the copy button. Replace every [bracketed placeholder] with your specific project details. The more specific you are, the better the output.

3

Adapt over time

Once you've used a prompt a few times, you'll know which parts to change for your stack. Keep a personal file of your most-used variants — they'll compound in value.

Getting Started

12 prompts

Use these before and at the very start of any new project. They set the foundation for everything that follows.

The Intent Worksheet Prompt

Use before writing a single line of code

▾

Before I write any code, help me complete an Intent Worksheet for this project. Ask me these four questions one at a time and help me sharpen my answers until they're specific enough to build from: 1. What does it do? (Complete this sentence: "This helps [who] to [action] so they can [outcome].") 2. Who is it for? (Describe the user's situation before this exists.) 3. What does "done" look like? (Write the 3–5 step journey a real user takes.) 4. What are you NOT building in v1? (Name 3 explicit exclusions.) Start with question 1. Don't move to question 2 until my answer to question 1 is specific enough.

Why it works: Forcing specificity before you start is the single highest-leverage thing you can do. A vague intent produces a vague project. This prompt won't let you escape with vague answers.

All levels

Architecture Options — Choose Your Foundation

After completing the Intent Worksheet, before any code

▾

I'm building [one-sentence description from Intent Worksheet]. Users: [who will use it] Core features for v1: [list from Intent Worksheet] Before any code: give me two architectural approaches with clear tradeoffs. For each option include: - Stack recommendation - Folder/file structure overview - Why it would or wouldn't scale to v2 - Estimated setup complexity (1–5) I'll choose one, then we build. Don't start building yet.

Why it works: Asking for options before committing forces a real architecture decision. The "don't start building yet" line is essential — without it, the AI will often start writing code mid-explanation.

Intermediate+

Session Context Block — Start Every Session With This

At the very start of every new AI session on an existing project

▾

# Project: [name] [One sentence: what it does and for whom] # Stack [Frameworks, key libraries, database, hosting] # What exists right now [Brief description of working features] # Naming and style conventions - [Your naming conventions, e.g. "camelCase for variables"] - [Error handling pattern] - [Component structure if applicable] # What NOT to change [Things that work and should not be touched] # Today's goal [What you want to accomplish this session] Ready to start. What's the first step?

Why it works: The AI has no memory between sessions. This block re-establishes the full project context instantly and dramatically improves output quality. The "what not to change" section prevents the AI from helpfully refactoring working code.

All levels

Tech Stack Recommendation for Beginners

When you don't know what stack to use

▾

I'm a beginner vibe coder. I want to build: [describe what you want to build in plain English] I have no strong preferences on stack. My priorities are: 1. Get it working as fast as possible 2. Be able to deploy it easily 3. Not have to understand a lot of infrastructure Recommend the simplest possible stack that can do this. Explain each part in one sentence. Don't recommend anything that requires DevOps knowledge.

Why it works: Without explicit constraints, AI tools often recommend enterprise-grade stacks to beginners. The constraints force a recommendation that matches your actual situation.

Beginner

Scaffolding

14 prompts

For generating the initial structure of an app, feature, or module. These prompts produce scaffolds — not finished code — and that distinction is intentional.

Full App Scaffold — Structure First

When starting a new project from scratch

▾

Build a [framework] app for [what it does]. Stack: [your stack] v1 features only: - [Feature 1] - [Feature 2] - [Feature 3] Start with the skeleton only: - Correct folder structure - Empty route/page files with comments describing what each will do - Package.json with all dependencies - A README with setup instructions Do NOT write any feature logic yet. Get the skeleton running with a "Hello from [app name]" on the home route, then stop.

Why it works: "Skeleton only" prevents the AI from building everything at once. A running skeleton gives you a checkpoint to verify before adding complexity.

All levels

Database Schema Design

Before writing any database code

▾

Design a [database type] schema for [app description]. Core entities needed: - [Entity 1 and what it represents] - [Entity 2 and what it represents] Rules: - Optimise for the queries I'll run most often: [describe your most common queries] - Include created_at/updated_at on everything - Show the SQL (or ORM model) to create each table - Note any indexes I should add and why Don't create migration files yet — just show me the schema so I can review it first.

Why it works: Database schemas are hard to change later. Reviewing them before implementing prevents structural debt that compounds quickly.

Intermediate+

API Route Structure

When designing a REST API

▾

Design the REST API routes for [app/feature]. For each route include: - Method + path - What it does - Request body shape (if applicable) - Response shape (success and error) - Authentication required? (yes/no) Then implement empty route handlers with the correct response shapes — no business logic yet, just the structure with placeholder responses.

Why it works: Designing routes before implementing them catches naming inconsistencies, missing endpoints, and authentication gaps before any code is written.

Intermediate

Iteration

15 prompts

For building features one focused step at a time. The best vibe coders iterate in small, testable loops — these prompts enforce that discipline.

One Feature at a Time

For every feature addition after the scaffold exists

▾

Add [specific feature] to the existing [file/module]. The feature should: - [Behaviour 1] - [Behaviour 2] - [Edge case to handle] Constraints: - Don't change [file/function that should stay the same] - Use the same patterns already in the codebase - Add error handling for [specific failure case] - Stop after this feature — don't anticipate the next one After writing the code, tell me exactly what to test to confirm it works.

Why it works: "Stop after this feature" and "don't anticipate the next one" are crucial. Without them, AI tools tend to add extra features and abstractions that look helpful but increase complexity and break other things.

All levels

UI Component — Functional First

When building any frontend component

▾

Build a [component name] component in [framework]. It needs to: - [Core function 1] - [Core function 2] - Handle: [edge case] - Handle: [empty/loading/error states] Step 1: Build the functional version with minimal styling — just enough to see it work. Step 2: I'll test it, then we'll add styling. Don't add animations, transitions, or extra features in step 1. Functional first.

Why it works: Separating functional correctness from styling reduces debugging complexity. You can't test functionality reliably when styling and behaviour are implemented simultaneously.

Beginner+

Add Validation to a Form

After a form works functionally

▾

Add validation to the [form name] form. Validate these fields: - [Field 1]: [rule, e.g. "required, valid email format"] - [Field 2]: [rule, e.g. "required, 8–100 characters"] - [Field 3]: [rule, e.g. "optional, but if present must be a URL"] Validation rules: - Validate on submit, not on every keystroke - Show error messages inline below each field - Clear field errors when the user starts typing again - Prevent submission if any required field fails Do validation server-side as well as client-side.

Why it works: The reminder to validate server-side is critical — client-side validation is easily bypassed. This prompt enforces both layers.

All levels

Debugging

14 prompts

When something breaks. These prompts help you diagnose quickly and fix precisely — rather than spray-and-pray patching that creates new bugs.

Error First — Paste and Diagnose

The moment you get an error message

▾

I'm getting this error: [PASTE FULL ERROR MESSAGE AND STACK TRACE HERE] Context: - This happens when I: [describe the action that triggers it] - It started after I: [describe the last change made] - Expected behaviour: [what should happen] - Actual behaviour: [what actually happens] Don't fix it yet. First: explain what this error means in plain English and what's likely causing it. Then give me 2–3 hypotheses ranked by likelihood.

Why it works: "Don't fix it yet" forces a diagnosis before treatment. Jumping straight to fixes without understanding the cause is how you end up with three fixes that each create a new problem.

All levels

Something Stopped Working After a Change

When working code breaks after you edited something

▾

[Feature] was working yesterday. After I [describe change], it now [describe broken behaviour]. Here's the relevant code before and after my change: BEFORE: [paste old code] AFTER: [paste new code] The error/symptom: [paste error or describe what's wrong] What did my change break, and what's the minimal fix?

Why it works: Showing the before/after diff dramatically narrows the search space. The AI can focus on what changed rather than scanning the entire codebase.

All levels

The AI Keeps Making the Same Mistake

When you've corrected the same issue more than twice

▾

You keep [describing the recurring mistake, e.g. "using var instead of const" / "forgetting to handle the null case"]. I have corrected this [number] times. Before we continue, I need you to: 1. Acknowledge the specific rule: "[state the rule clearly]" 2. Scan the existing code and find every other place this mistake might exist 3. Fix all instances now Going forward, treat this as a hard constraint, not a suggestion. Confirm you understand.

Why it works: Explicitly naming recurring mistakes and asking for a scan-and-fix prevents the same issue appearing in new code. The confirmation request creates a checkpoint.

All levels

Architecture

13 prompts

For structural decisions that shape the project for months. Use these when the AI proposes something structural, or when you need to review where the project is heading.

Architectural Review — The Pause Prompt

Every 10–15 significant changes, or before adding a major feature

▾

Stop building. I want to review where we are before continuing. [Paste current project structure or key files] Questions: 1. Is the current structure consistent with the decisions we made at the start? 2. What technical debt has accumulated? 3. Will adding [next planned feature] be natural given this structure, or will it require awkward changes? 4. What, if anything, should I refactor now before it becomes expensive later? Be honest about problems. I'd rather know now.

Why it works: "Stop building" is the key phrase. The AI defaults to continuing — this prompt forces a genuine review pause. "Be honest about problems" produces more candid assessments.

Intermediate+

Evaluate an AI Architectural Proposal

When the AI suggests a new pattern or structure

▾

You've proposed [describe the architecture proposal]. Before I accept this, I want to stress-test it: 1. What problem does this solve that the current approach doesn't? 2. What does it make harder that's currently easy? 3. How many files would change if we adopted this? 4. What would a rollback look like if it causes problems? 5. Is there a simpler version of this approach that captures 80% of the benefit? Answer these honestly. I'll decide whether to proceed.

Why it works: AI tools sometimes propose overly complex architectural solutions. This prompt forces explicit cost-benefit analysis before you commit to something structural.

Advanced

Security

12 prompts

Security prompts to run before shipping anything to real users. These are not optional — AI-generated code can look clean while having serious vulnerabilities.

Pre-Launch Security Audit — Full

Before deploying to production

▾

Run a security audit on this code before I deploy it. [Paste code or describe the app] Check specifically for: 1. Input validation — is everything validated server-side? 2. SQL injection / query injection vulnerabilities 3. Authentication gaps — can unauthenticated users access anything they shouldn't? 4. Authorisation gaps — can authenticated users access other users' data? (IDOR vulnerabilities) 5. Sensitive data — are any secrets, API keys, or passwords visible in code or error messages? 6. Error handling — do errors reveal internal details? 7. Rate limiting — can any endpoint be abused? Format: List each issue found with (a) the vulnerable code, (b) the risk, and (c) the fix. Severity: Critical / High / Medium / Low. Only show real issues, not theoretical ones.

Why it works: The structured format forces specificity — "only real issues" prevents the AI from listing every theoretical vulnerability in existence. Severity rating helps you prioritise what to fix before launch vs. later.

All levels

Authentication Flow Review

After implementing any authentication system

▾

Review my authentication implementation: [Paste auth-related code] Specifically check: - Are sessions stored securely? - Is the session refreshed correctly on expiry? - Can a user access a protected route without being authenticated? - What happens if the auth token is invalid or expired? - Are passwords hashed correctly (bcrypt or Argon2, not MD5 or SHA1)? - Is there any way to forge or bypass authentication? Show me the exact code for any issues found.

Why it works: Auth bugs are silent — they look like they work until someone exploits them. This prompt catches the most common implementation mistakes before launch.

Intermediate+

Refactoring

11 prompts

For improving code that works but needs cleaning. Refactoring prompts are most useful once you have a passing test suite to verify nothing breaks.

Targeted Module Refactor

When a specific file or function has grown unwieldy

▾

Refactor [file/function name]. The problem: [describe what's wrong — too long, too complex, too many responsibilities, etc.] The goal: [what better looks like] Hard constraints: - Do NOT change the public interface (how other code calls this) - Do NOT add new dependencies - Maintain existing error handling patterns - The behaviour must be identical before and after Show me the refactored version. Add a comment for each significant structural change explaining why.

Why it works: "Do not change the public interface" prevents refactors that break callers. The comment requirement forces intentional changes rather than mechanical reformatting.

Intermediate+

Reduce Duplication — DRY Pass

When you notice similar code appearing in multiple places

▾

I have duplicated logic across these files: [Paste the duplicated sections] Propose an abstraction that: - Removes the duplication - Is named clearly (not "utils" or "helpers") - Doesn't over-abstract — only extract what's genuinely shared, not what's merely similar Show me: (1) the abstraction, (2) how each file would use it, and (3) any edge cases where the files differ that the abstraction needs to handle.

Why it works: The "don't over-abstract" constraint prevents AI tools from creating deeply nested abstraction hierarchies that are harder to understand than the original duplication.

Advanced

Context Management

10 prompts

For managing the AI's understanding of your project across sessions and as the codebase grows. Context management is the most underrated skill in vibe coding.

Generate a Context Document

After building the initial scaffold, or mid-project

▾

Based on everything we've built so far, generate a context document I can paste at the start of future sessions. Include: - What this project does (2 sentences) - The current tech stack - What each main file/folder does (one line each) - Key conventions: naming, error handling, code style - Current working features - Known issues or technical debt - Things to never change without careful review Format as Markdown, under 400 words. I'll save this as AI_CONTEXT.md in the repo root.

Why it works: A well-maintained AI_CONTEXT.md is the difference between sessions that produce consistent, architecture-aligned code and sessions that drift. Generate one early and update it with each major change.

All levels

Onboard the AI to an Existing Codebase

When starting work on a codebase the AI has never seen

▾

I'm going to share files from an existing codebase one at a time. For each file: 1. Tell me what it does in one sentence 2. What it depends on 3. Patterns or conventions I should maintain 4. Any problems you notice Don't suggest changes yet — just understand the code. After I've shared all the files, summarise the overall architecture and tell me where the biggest risks are. First file: [paste file]

Why it works: "Don't suggest changes yet" is essential. The AI instinct is to immediately propose improvements. Getting a clear understanding first leads to much better, more contextual suggestions later.

Intermediate+

Session Summary — End of Session

At the end of every work session

▾

We're ending this session. Summarise what we did: 1. What we built or changed 2. What's working now that wasn't before 3. Any unresolved issues or loose ends 4. What the obvious next step is I'll paste this at the start of the next session. Keep it under 200 words.

Why it works: This creates a handoff document between sessions. Starting the next session with "last time we..." instantly restores context without re-reading the whole conversation.

All levels