8 Vibe Coding Prompts - The Full Pack

Vibe coding is changing the way we build software with AI. The right prompt can save time, improve your code, and help turn ideas into working projects faster.

Here are 8 useful vibe coding prompts worth saving and trying in your next project.

How to use this

1. Hit the copy button on any code block below.
2. Replace anything in [BRACKETS] with your own details.
3. Don't skip the parts that tell the AI to ask first / audit before changing. That's the whole reason these work.

Best order for a new project: 1 → 2 → build → 3 → 5 → 6 → 7

Best order when you're stuck: 4 → 3 → 6

1. Write a Full PRD

Stop starting with "build me an app." Start with a spec the AI wrote with you.

You are a senior product manager. I want a complete PRD for the product below.

Product idea: [DESCRIBE YOUR IDEA]

Before writing anything, ask me up to 5 clarifying questions about the target user, must-have vs nice-to-have scope, technical constraints, and what "done" looks like. Wait for my answers.

Then output the PRD with these sections:
1. Problem statement — who hurts and why
2. Target user + 2 personas
3. Goals and non-goals
4. User stories in "As a... I want... so that..." format
5. Feature list split into MVP / v2 / later
6. Detailed functional requirements per MVP feature
7. Data model sketch (entities + key fields)
8. Edge cases and failure states
9. Success metrics
10. Open questions

Be specific and opinionated. No filler. If a requirement is ambiguous, flag it rather than inventing it.

Pro tip: save the output as PRD.md in your repo root. Every future prompt gets smarter because of it.

2. Full UI & UX Design Brief

Design before you code. This is what stops every app looking like the same purple gradient template.

You are a senior product designer. Using the PRD above, produce a complete design brief before any code is written.

Deliver:
1. Design principles — 3 rules this product's UI must obey
2. Visual direction — mood, references, what to avoid
3. Design tokens — color palette with hex + usage, type scale, spacing scale, radius, shadows
4. Screen inventory — every screen with its purpose
5. User flows — step by step for each core journey
6. Per-screen layout — sections, hierarchy, primary action, components used
7. Component library — every reusable component with its variants and states
8. States — empty, loading, error, success, offline for each key screen
9. Responsive behaviour — mobile, tablet, desktop
10. Accessibility — contrast ratios, focus order, keyboard nav, ARIA needs

Make deliberate choices and justify each one. Avoid generic defaults. If you're choosing a font or color, tell me why it fits this specific product.

Pro tip: save as DESIGN.md. Then tell the AI "follow DESIGN.md" on every UI task.

3. Find Security Gaps

The step everyone skips. Run it before you deploy, not after.

Act as an application security engineer doing a pre-launch audit of this codebase.

Review for:
- Authentication and session handling flaws
- Authorization gaps (can user A reach user B's data?)
- Hardcoded secrets, keys or tokens; anything sensitive exposed client-side
- Injection risks (SQL, NoSQL, command, XSS)
- Unprotected or unvalidated API routes
- Missing input validation and sanitization
- Missing rate limiting / brute force protection
- Insecure direct object references
- Over-permissive CORS, missing security headers, unsafe cookie flags
- Known-vulnerable dependencies
- Sensitive data leaking into logs or error responses

For each finding give me:
- Severity: Critical / High / Medium / Low
- File and line
- How it would actually be exploited
- The exact code fix

Then list all findings ranked by severity. Do NOT modify any code until I approve. If a category is clean, say so explicitly rather than staying silent.

4. Debug an Error Fast

Kills the "try this... no wait, try this" death loop.

I have a bug. Do NOT write any fix yet.

Error / unexpected behaviour: [PASTE THE ERROR]
What I expected: [DESCRIBE]
What actually happens: [DESCRIBE]
Relevant code: [PASTE OR POINT TO FILES]
What I already tried: [LIST]

Step 1: Restate the problem in your own words so I know we agree.
Step 2: List the 3-5 most likely root causes, ranked by probability, each with your reasoning.
Step 3: For each cause, give me the single fastest way to confirm or eliminate it — a log line, a check, a one-line test.
Step 4: Stop and wait for my results.
Step 5: Only once we've confirmed the cause, write the minimal fix, explain why it works, and tell me exactly what to test to verify.

Don't shotgun changes. Don't refactor unrelated code. Don't fix things I didn't ask about.

5. E2E Test Your App (Playwright)

Ship without holding your breath.

Set up end-to-end testing for this app with Playwright.

1. Install and configure Playwright for this stack. Add config for local + CI, with retries, traces on failure, and screenshots.
2. Identify the critical user journeys from the codebase and list them for my approval BEFORE writing any tests.
3. For each approved journey, write tests covering the happy path plus realistic failure states (bad input, expired session, network error, empty data).
4. Use resilient selectors — prefer role-based or data-testid. Add the missing data-testid attributes to components where needed.
5. Create an auth fixture so logged-in tests don't repeat the login flow every run.
6. Add test data seeding and cleanup so tests are isolated and repeatable.
7. Add npm scripts: test:e2e, test:e2e:ui, test:e2e:ci
8. Add a CI workflow that runs the suite on every PR.

Explain how to run everything. Flag any journey that can't be reliably tested and tell me why.

6. Clean Up & Refactor Dead Code

Vibe coding leaves a mess. A smaller codebase also makes every future AI response smarter.

Act as a senior engineer doing a cleanup pass on this repo. Work in two phases and stop between them.

PHASE 1 — AUDIT (make zero changes):
Find and list, with evidence that each is genuinely unused:
- Unused files, components, hooks, utils
- Unused imports, variables, functions, exports
- Unused dependencies in package.json
- Unused env vars, routes, API endpoints
- Commented-out code blocks
- Logic duplicated in 2+ places
- Files that have grown too large and should be split

Present this as a table with a risk level for each deletion. Flag anything you are less than 90% confident about — do NOT delete those. Then stop and wait.

PHASE 2 — EXECUTE (only after I approve):
- Delete what I approved
- Extract duplicated logic into shared utilities
- Split oversized files along clear responsibility lines

Rules: behaviour must remain identical, no new dependencies, no renaming public APIs. Give me a summary of every change so I can review the diff.

7. Write Clean Git Commits

No more fix stuff × 40. Your history becomes documentation.

Review my current changes (staged and unstaged) and organise them into clean commits.

1. Summarise what actually changed and why, grouped by intent.
2. Split the work into atomic commits — one logical change each. If something mixes a fix and a refactor, separate them.
3. For each commit write a Conventional Commits message:
   type(scope): short imperative summary under 60 chars
   
   Then a blank line and a body explaining WHY the change was needed and any tradeoffs. Mark breaking changes with BREAKING CHANGE:.
4. Order the commits so the repo builds and tests pass at every single step.
5. Output the exact git commands to run in sequence, including which files go in which commit.

Types: feat, fix, refactor, perf, docs, test, chore, style, build, ci
Never write vague messages like "update", "fix stuff", "changes" or "wip".

8. Turn a Task Into a Skill

The one that compounds. Do the work once, never explain it again.

We just completed a task together. Turn it into a reusable Skill so I never have to explain it again.

The task: [DESCRIBE, OR SAY "what we just did"]

Produce:
1. Name — short, action-oriented
2. Description — a precise trigger description: exactly when this Skill should and should NOT be used, including the phrasings a user might realistically say. Specific enough that it fires reliably and never fires on unrelated tasks.
3. Instructions — numbered, step-by-step, written for a model with zero prior context. Include what to check first, what to ask the user, and what order to do things in.
4. Rules and constraints — hard requirements, and what must never happen.
5. Output format — exactly what the result should look like, with a template.
6. Worked example — one full input-to-output example.
7. Failure modes — the 3-5 ways this commonly goes wrong and how to avoid each.

Write it so it works standalone. Assume the reader knows nothing about this project.

The pattern behind all 8

Every one of these does the same three things:

• Assigns a role - "senior PM", "security engineer", "product designer"
• Forces a pause - ask questions first, audit before changing, diagnose before fixing
• Defines the output - exact sections, exact format, no guessing

Steal the pattern, not just the prompts.

Subscribe below for more content, and follow Coding Dev on Instagram if you haven’t already.