the four prompts i run before any new feature

most bad vibe-coded features go wrong before the model writes a line. the builder jumps straight from idea to implementation, the agent guesses at the codebase, and everyone spends the next hour cleaning up avoidable weirdness.

the fix is not a longer master prompt. the fix is a short preflight. before any new feature, i run four prompts that force the agent to understand the project, surface risk, define the contract, and choose a small first pass.

1. map the surface area

do not ask for code first. ask the agent to find the files and patterns it expects to touch.

inspect this repo for the feature i am about to add.
return:
- the files likely involved
- the existing patterns i should match
- anything that looks like a trap
do not edit files yet.

this catches the obvious misses: the form helper already exists, the route naming convention is different than you assumed, the state lives one level higher than the page you were staring at.

2. name the failure modes

once the agent knows the neighborhood, make it say what could break. you are not looking for a giant risk register. you are looking for the three or four things worth keeping in your head while you build.

given that map, what are the likely failure modes?
focus on:
- user-facing regressions
- data loss or bad state
- build/test failures
- responsive layout problems
rank them by likelihood and impact.

models are very good at sounding confident while stepping on a wire. this prompt makes the wire visible.

3. define done before doing

if you do not define the finish line, the model invents one. sometimes that is fine. usually it means you get a demo-shaped feature instead of the thing you meant.

write the acceptance contract for this feature before building it.
include:
- what the user can do
- what states must exist
- what should happen on errors or empty data
- what tests or checks prove it works
keep it concrete.

the contract is not bureaucracy. it is how you stop the agent from optimizing for "looks done" instead of done.

4. ship the smallest useful pass

now ask for the implementation, but force the scope down. big prompts create big ambiguity. small passes create momentum.

implement the smallest useful version of this feature.
stay inside the existing patterns.
do not add dependencies unless you explain why first.
after editing, run the narrowest relevant verification and report exactly what changed.

the magic phrase is "smallest useful." not smallest possible. not the whole imagined roadmap. useful means a real user can touch it and get value. smallest means you can still reason about the diff.

the sequence matters

run these in order. surface area, failure modes, done contract, smallest useful pass. each answer improves the next prompt. each answer gives you a chance to steer before the agent has already poured concrete.

that is the real skill: not writing one perfect incantation, but keeping the model in a tight feedback loop where its next action is always grounded in the project in front of you.