Vibe coding prompts that actually ship.

Stops the agent from guessing: it has to show the bug happening first.

There's a bug: [describe what happens and what you expected].

Before you change any code:
1. Find the smallest way to reproduce it (a command, a test or a request) and run it so we both see it fail.
2. Explain the root cause with file:line references. If you have more than one theory, rank them and say what would tell them apart.
3. Propose the smallest fix and wait for my OK.

After I approve: make the fix, run the reproduction again to show it passes, and run the existing tests for the area you touched.

For when you have a stack trace and no idea where it really started.

Here's an error from [where it happened: dev server, CI, production log]:

[paste the full error and stack trace]

Walk the trace from the top frame down into our own code (skip framework internals). For each of our frames, read the code and say what values could reach it. Then tell me the most likely cause, the evidence for it, and one quick check that would confirm it. Don't edit anything yet.

Runs the test until it fails, then finds the shared state or timing behind it.

The test [test name or file] passes sometimes and fails sometimes.

1. Run it in a loop (at least 20 times, or until it fails) and keep the failing output.
2. Look for the usual causes: shared state between tests, test order, real timers or dates, network calls, randomness without a seed, and parallel runs touching the same files or ports.
3. Tell me which one it is, with evidence, then fix the test (not the product code, unless the product code is the bug) and prove it with another 20 passing runs.

Covers your actual diff, including the edge cases, without touching the implementation.

Look at my uncommitted changes (git diff) and write tests for the behavior they add or change.

- Follow the test framework, file layout and naming this repo already uses.
- Cover the happy path, empty and invalid input, boundaries, and one failure path for each changed function.
- Don't change the implementation. If something is hard to test, tell me why instead of rewriting it.
- Run the new tests and the existing suite for those files, and show me the results.

A ranked list of where a bug would hurt most and nothing would catch it.

Find the code in this repo that is both risky and untested. "Risky" means it handles money, auth, user data, deletes things, or has a lot of branches.

Give me a ranked top 10 with file:line, why it's risky, and what a test for it should check. Don't write the tests yet.

Bugs and risks first, with file:line and severity. No style nitpicks.

Review the changes on this branch against main (git diff main...HEAD).

Report only real problems, most severe first: bugs, missing error handling, race conditions, security issues, data loss, performance traps and breaking changes. For each: file:line, what goes wrong and how to trigger it, and a suggested fix.

Skip formatting and naming preferences. If you find nothing serious, say so plainly.

Checks input handling, auth, secrets and injection in the code you point it at.

Do a security review of [feature, folder or endpoint].

Check: every place user input is used (SQL, shell, file paths, HTML, redirects); authentication and authorization on each route or action; secrets in code, logs or the frontend bundle; rate limits on expensive or sensitive actions; and what an attacker could do with the IDs or URLs we expose.

List findings with file:line, impact and a fix. Mark anything you're unsure about as "needs a closer look" rather than guessing.

Small, tested steps, so you can stop at any point with working code.

Refactor [file, module or function] to [goal: e.g. split it up, remove duplication, make it testable].

Rules:
- Behavior must not change. If there are no tests covering it, write characterization tests first and run them.
- Work in small steps. After each step, run the tests and commit with a message that says what moved.
- Don't rename public APIs or change file locations other code imports from, unless I ask.
- At the end, show me a summary of the steps and anything you noticed but left alone.

Finds unused exports, files and flags, and proves they are unused before removing them.

Find dead code in this repo: unused exports, files nothing imports, feature flags that are always on or off, and commented-out blocks.

For each candidate, show the evidence that it's unused (searches for its name, dynamic imports, config references, routes). Group them into "safe to delete" and "probably unused, check with me". Delete only the safe group, then run the build and tests.

The agent runs every command itself, so the setup steps actually work.

Write (or rewrite) the README for this repo for someone who just cloned it.

Include: what the project does in two sentences, requirements with versions, setup, how to run it locally, how to run the tests, the environment variables (names and what they're for, never real values), and the folders that matter.

Run every command you put in the README and fix the README (not the code) where they don't work as written. Keep it short; link to deeper docs instead of copying them.

Adds comments only where a decision isn’t obvious from the code.

Go through [file or folder] and add comments only where the code would surprise a careful reader: a workaround, a non-obvious constraint, an ordering that matters, a magic number, or a decision someone might "fix" by mistake.

Don't comment what the code already says. Remove comments that are wrong or out of date. Show me the diff.

Turns one feature into lanes that don’t step on each other’s files.

I want to build [feature] with [number] agents working in parallel.

Read the codebase, then split the work into that many lanes. For each lane give: its goal, the files it owns (no file may be owned by two lanes), what it needs from other lanes, and how we'll know it's done (a test or a command).

Before the lanes, list the shared contracts (types, API shapes, database changes) that must be agreed first, and put them in a lane of their own that runs before the others. Point out anything that can't be split safely.

Paste into each parallel agent so it stays in its lane and reports back cleanly.

You are one of several agents working on this repo at the same time.

Your lane: [goal of this lane]
Files you own: [list]. You may read anything, but only edit these. If you need a change elsewhere, stop and tell me what and why.
Work on the branch [branch name] (in your own git worktree if one was set up). Commit in small steps.

When you're done: run the tests for your files, then report what you changed, how you verified it, and anything the other lanes need to know.

Brings parallel branches together one at a time, with tests between each.

Several agents worked in parallel on these branches: [list branches].

Merge them into [target branch] one at a time, in an order that makes sense (shared contracts first). After each merge, run the build and the full test suite. If there's a conflict, explain what each side intended before resolving it; don't just pick one. Stop and ask me if two branches changed the same behavior in different ways.

At the end, give me a short summary of what landed and anything still broken.

Gives Claude Code the commands, conventions and gotchas it would otherwise rediscover every session.

Create a CLAUDE.md at the root of this repo for future Claude Code sessions.

Include only what isn't obvious from the code: how to install, build, run and test (exact commands, verified by running them); the conventions we follow (folders, naming, patterns to copy); things that look safe to change but aren't; and anything that commonly goes wrong. Keep it under 80 lines and don't repeat what's already in the README.

The same project briefing, in the file Codex reads.

Create an AGENTS.md at the root of this repo so Codex knows how to work here.

Cover: the exact commands to install, build, lint and test (run them to check); the code conventions to follow; folders or files to leave alone; and how to verify a change before calling it done. Keep it short and specific to this repo.

Captures your conventions as a rule Cursor’s agent applies in this project.

Write a project rule for this repo in .cursor/rules.

Base it on what you can see in the code: the framework and versions, folder structure, how components or modules are written, how errors are handled, and how tests are named. Write it as short, direct instructions ("Use X", "Don't do Y"), with one example where a rule could be misread. Only include rules the existing code actually follows.

Gives Gemini CLI the project context it should load every time.

Create a GEMINI.md at the root of this repo with the context Gemini CLI should have every session.

Include: what the project is, the commands to build, run and test (verified by running them), the main folders and what lives in each, our conventions, and the mistakes to avoid. Keep it concise and specific; skip anything generic.

Turns a written spec into a plan and a first working slice, instead of a giant half-finished app.

Read PRD.md in this repo. Don't write code yet.

1. Propose the file structure, the data model and the list of screens or endpoints, based only on what the PRD asks for.
2. Split the build into milestones, each one small enough to test by hand.
3. Wait for my OK.

Then build milestone 1 only: make it run, tell me exactly how to try it, and stop. Don't add features the PRD doesn't mention.

A focused mobile pass: no sideways scrolling, readable text, tappable buttons.

Make this app work well on phones without changing how it looks on desktop.

Check every page at 375px and 768px wide: no horizontal scrolling, text at least 16px, buttons and links at least 44px tall, nothing cut off or overlapping, and forms usable with a phone keyboard. Fix what's broken with the styling approach the project already uses.

List each page with what you changed. Don't touch desktop layouts unless something is broken there too.

Spacing, alignment, empty states and loading states: the details that make an app feel finished.

Do a UI polish pass on [page or whole app], keeping the current design.

Fix: inconsistent spacing and font sizes, misaligned elements, buttons with no hover or focus state, missing loading states, empty states that show nothing, error messages that are unclear, and low-contrast text.

Don't redesign, add features or new dependencies. Show me a short before/after list per page.

For when you vibe-coded something and now need to understand how it actually works.

I want to understand this codebase. Explain it to me like I'm a smart beginner.

Start with: what the app does, how a request or a click flows through the code (name the actual files), where the data lives, and how it's deployed. Then list the five files I should read first and why.

Use plain words and short sections. Point out anything that looks fragile or risky while you're at it, but don't change any code.