Vibe Coding Prompts: Templates That Keep a Project Sane

A good vibe coding prompt template has five parts: the goal in one sentence, the limits of the change, what to read first, a request for a plan before any code, and the check that proves it worked. Leave out the limits and the AI changes twelve files for a one-line request. Leave out the plan and you find out what it misunderstood after it has built the wrong thing. Leave out the check and “done” means “looks done”. The six templates below put those five parts into the prompts you actually need: starting a project, adding a feature, fixing a bug, reviewing, refactoring and preparing to ship. Copy them, replace the parts in angle brackets, and keep the rest.

These are prompts for a coding assistant working on a real project, in an editor, a terminal or an app builder. How to word any single request to Claude is covered in Claude prompting best practices, and the document you write before a larger build is in a PRD for AI coding agents. Neither is repeated here.

The five parts, and why each one is there

• Goal. One sentence a colleague would understand: what should be true when the work is finished. If you cannot write it in one sentence, the task is two tasks.
• Limits. Which files or folders the change may touch, what must not change, and what is out of scope. This is the part that keeps a project sane: an assistant with no limits “improves” whatever it passes on the way.
• Context. The file, error message, screenshot or existing pattern to read first. Pointing at an example in your own code gets you code that looks like the rest of the project.
• Plan first. Ask for the plan and stop. Reading five lines of plan takes less time than reading a diff, and a wrong assumption is cheap to fix before any code exists.
• Check. A command, a test or a thing to try in the browser, and a request to show the result. Without it the assistant stops when the work looks finished, and you become the test suite.

Tool makers recommend the same shape. Anthropic’s Claude Code best practices↗ (opens in a new tab) describe exploring, then planning, then coding, and say that giving Claude a check it can run, such as tests, a build or a screenshot to compare, is the difference between a session you watch and one you can walk away from. GitHub’s prompt engineering guide for Copilot↗ (opens in a new tab) makes the scope point: break a complex task into several simple, small tasks, and be specific about which code you mean.

1. Starting a project

I want to build <one sentence: who it is for and what it does>.

Before writing any code, interview me: ask up to 8 questions about the
parts I have not thought through (data, sign-in, edge cases, what is
out of scope). Then write a short plan:
- the stack you propose and why, in 3 lines
- the smallest first version that I can run and click through
- the list of later features, NOT to be built yet

Stop after the plan. Do not create files until I say "go".

When I say go: build only the first version, give me the exact
commands to install and run it, and run them yourself first.

The interview is there because your first sentence leaves out the decisions that matter, and an assistant will otherwise fill them in silently. The “later features” list turns every idea it has into a written item instead of code. The last line makes the first check simple: it runs on a clean machine, or it does not.

2. Adding a feature

Add <feature> so that <who> can <do what>.

Read first: <file or folder>, and follow the pattern in <example file>.
Limits: change only what this feature needs. No new dependencies
without asking. Do not touch <auth / payments / migrations>.

First reply with a plan: the files you will change, anything you will
add, and anything you are unsure about. Wait for my OK.

Done means: <the check, e.g. "a signed-in user can add a note and see it
after a refresh">. Run <test or build command>, and show me the output.
If you notice other problems, list them at the end. Do not fix them.

The last line does most of the work. Assistants notice things, and the natural next step is to fix them in the same change. A list at the end keeps the diff to one feature and keeps the ideas.

3. Fixing a bug

Bug: <what happens> when <steps>. Expected: <what should happen>.
Error, exactly as shown: <paste it>.
Likely area: <file or folder>, but confirm before changing anything.

First, explain the cause in 2-3 sentences and point to the line.
Then write a test (or a script) that fails because of this bug.
Then fix the cause, not the symptom: do not suppress the error, catch
it and carry on, or delete the failing check.

Done means: the new test passes, <existing test command> still passes,
and you show me both outputs.

Asking for the cause before the fix stops the most common failure in vibe coding: fix attempts piled on fix attempts, each one left in the code. The failing test proves the bug was understood. The “do not suppress” line is there because silencing an error is the quickest way to make a symptom go away.

4. Reviewing what was built

Review the changes on this branch against <the plan or task>.
Do not edit anything.

Report, with file and line:
1. Anything the plan asked for that is missing.
2. Anything changed that the plan did not ask for.
3. Bugs: wrong logic, unhandled empty or error cases, race conditions.
4. Anything that trusts the browser: missing server-side checks,
   secrets in client code.

Only report problems that affect correctness or the plan. No style
opinions. For each, say how sure you are.

Run it in a new session, or with a different assistant, so the reviewer is not grading work it has just argued for. Anthropic’s guidance makes the same point about a fresh context and warns that a reviewer asked to find gaps will find some; limiting it to correctness keeps you from chasing opinions. Point 4 is only a first pass: the full list of what to check before real users arrive is in vibe coding security.

5. Refactoring

Refactor <file or module> to <goal: split it up / remove duplication /
rename X to Y>.

Behaviour must not change. Before touching anything:
- run <test command> and show me the result
- if there are no tests for this code, write tests that pin down what it
  does today, and show them passing

Plan the refactor in small steps, each one leaving the app working.
After each step, run the tests. Stop and tell me if any fail.
Do not add features or fix unrelated bugs during the refactor.

A refactor is only safe if something tells you the behaviour stayed the same, which is why the tests come before the change, not after it. Small steps mean a failure points at one step, and your git history or the tool’s checkpoints can take you back to the last good one.

6. Preparing to ship

We are about to put this in front of real users. Do not change code
yet. Go through the project and report, with file and line:

- every secret or API key and where it is read (server or browser)
- every API route, and whether it checks who is calling and whether
  the record belongs to them
- every database table, and what stops one user reading another's rows
- error pages: what a user sees when something fails
- dependencies you added that I may not know about
- commands to build, test and run in production, and whether they pass

Then give me a list of fixes, most serious first. We will do them one
at a time, each as its own change with its own check.

This is an inventory, not a fix-everything prompt. Asked to “make it production ready”, an assistant will change dozens of files at once and you will not be able to tell what broke. An inventory turns into a list, and each item on the list goes back through template 2 or 3.

Reading the plan before you say go

Most tools now have a mode for this. In Claude Code, plan mode lets it read files and propose a plan without making changes. Cursor’s Plan Mode↗ (opens in a new tab) researches the codebase, asks clarifying questions and produces a plan you can edit before it builds. The prompts above ask for a plan in words, so they work in any tool, with or without a mode. When the plan comes back, look for four things:

• Files it will change that have nothing to do with the goal.
• New libraries you did not ask for.
• Assumptions stated as facts, such as “users are already signed in here”.
• A missing check. If the plan ends without saying how it will prove the change works, ask for one before you approve it.

If a session goes wrong twice in a row, start a new one with a better prompt rather than correcting a third time. Save working states as you go: Claude Code’s checkpoints↗ (opens in a new tab) can rewind its own edits, but they are not a replacement for committing to git after each step that works.

Where the prompt’s parts live afterwards

A prompt disappears into chat history, and with it the goal, the plan and whether anyone checked. On a fenbs board each part has a place. The goal and limits go in the task’s note, written once. The plan goes in the task’s plan, which the assistant writes before it starts and rewrites as it learns. The check goes in the test status, Tested, Partly tested, Failed or Needs owner check, with notes saying what was run and what was not. The “list them, do not fix them” items become new tasks in To Do, each a feature, an enhancement or a bug.

An assistant connected over MCP does this with fenbs_get_item to read the task, fenbs_update_item to write the plan and the test result, and fenbs_create_item for what it noticed. Rules you want in every session, such as “no new dependencies without asking”, can go in the board’s AI context, which the assistant reads with fenbs_get_context before it starts. fenbs does not store or run prompt templates; keep those in your project or your tool.