Claude Code prompts worth stealing

Most prompts that disappoint ask for an outcome. "Fix the login bug." "Make this faster." The model obliges, produces something plausible, and you find out later whether it was right.

The prompts below ask for a method, and for the evidence that method produced. That single shift is most of the difference.

Each one belongs to a moment. This is the map, and every entry jumps to its prompt.

#Make it prove the bug exists

Before you fix anything, write a test that fails because of this bug.
Run it and paste the actual failure output. Then fix it, and run the same
test again and paste the pass. If you can't reproduce it, stop and tell me
what you'd need in order to.

Without this, you get a fix for the bug the model imagined. With it, you find out in the first 30 seconds whether it understood the problem, and the test outlives the fix.

#Make it measure instead of guess

Don't tell me what you think is slow. Instrument it, run it, and paste the
numbers. Then explain what the numbers say.

Models are excellent at generating a plausible cause and terrible at knowing whether it is the real one. A number settles it. This is the prompt I reach for most.

#Force the mechanism, not the story

Give me the exact chain from entry point to failure: what calls what, with
file:line at every step. Any link you have not confirmed by reading the code,
label UNVERIFIED.

The UNVERIFIED label is doing the work. It gives the model an honest place to put a guess, so it stops dressing guesses up as findings.

#Kill "looks done"

List the acceptance criteria for this task as checkboxes first. When you're
finished, go back through the list and mark each PASS or FAIL with the
command output that proves it. Anything you skipped goes under "not done".

#Hold the scope

Do exactly this and nothing else. If you spot other problems, collect them in
a list at the end instead of fixing them.

Scope creep in an agent is not laziness, it is helpfulness with no brakes. This gives the helpfulness somewhere to go.

#Make it read before it writes

Before writing any code: show me the three files most relevant to this change
and one line each on what they currently do. Then stop and wait.

Half of all bad changes are a correct solution to a misread codebase. Ten seconds of reading buys you that back.

#Ask what it would break

What are the three most likely ways this change breaks something that works
today? For each one, tell me how you checked, or say you didn't.

#Break a loop

You've now tried the same approach three times. Stop coding. List three
different hypotheses for what's actually wrong, ranked, and say what evidence
would tell them apart. Don't write anything until I pick one.

When a model is stuck it tends to retry with variations. Forcing hypotheses out of it converts thrashing into a decision you can make.

#Get a review, not a compliment

Review this the way you would if you had to defend approving it to someone
senior. Your default position is "changes requested". Only approve if you
genuinely cannot find anything real.

Naming the default is the trick. Without it, "review this" reliably returns praise.

#Get a plan you can actually land

Plan this as a sequence of commits. Each one independently reviewable, each
leaving the build green. For each: what changes, and the command I run to
verify it.

#Make it tell the truth about tests

Run the full suite and paste the summary line verbatim. If anything fails,
errors, or is skipped, say so before you tell me the work is done.

"Verbatim" is load-bearing. A summarised test result is where "all tests pass, except two unrelated ones" is born.

#Make the plan visible before the work starts

Write the todo list first, one item per independently verifiable step, and
show it to me before you touch anything. If a step turns out to be two steps,
split it and say so.

A todo list you can see is a plan you can correct. The cost of fixing item 4 before any code exists is a sentence; after the work, it is a rewrite. The second sentence matters as much as the first, because the honest failure is a model quietly widening one item rather than admitting the plan was wrong.

#Give a loop a stopping condition

Repeat until the suite is green: run it, take the top failure only, fix that
one, re-run. After each pass tell me the failure count. If the count doesn't
drop two passes in a row, stop and tell me what you're stuck on.

Anything you ask a model to repeat needs three things: the unit of work, the signal that it is finished, and the tripwire for when it is not converging. Leave out the third and a loop will happily grind for twenty minutes producing variations on the same broken idea.

#Start a session on solid ground

Read <file> and tell me the invariants I must not break, and anything that
looks deliberately weird. Then I'll tell you what I want to change.

Half the value is what comes back under "deliberately weird". That is usually where the last person's hard-won bug fix lives.

#What they share

Look back at the fourteen and the pattern is the same each time. Each one names the evidence up front, gives the model an honest way to report failure, or removes a decision it should not be making quietly.

The corollary is worth saying out loud: if a prompt keeps failing in the same way, add the missing evidence requirement to it rather than rephrasing it. Rephrasing changes the wording. Requiring output changes the outcome.