Claude Code Prompts That Actually Finish the Job

Work on this task end to end until it is done. Do not stop at the first plausible solution. After you change code: run it, show me the exact command you ran and the real output, and confirm nothing else broke. If you are blocked, state the one blocking question plus your best assumption, then keep going. Definition of done: it builds, it runs, I can see it working, and you proved it with output.

Forces run-and-prove instead of "this should work" - the #1 reason agents look done but aren't.

Run this loop until the goal is met: (1) make the smallest change toward the goal, (2) run the tests or the app and paste the real result, (3) if it failed, find the root cause and fix it, (4) repeat. Stop only when the goal is verifiably met or you hit a true blocker. Report each pass as Ran: <command> / Saw: <result>.

Turns one-shot attempts into a self-correcting loop that converges on working code.

Review the change you just made as a hostile senior engineer who assumes it is broken. List concrete bugs, edge cases, and anything that could fail in production, each with the file and line. Do not defend the code. Then fix every issue you found and re-verify with real output.

Catches the bugs the author is blind to - have it grade its own work harshly.

# Project rules (Claude Code reads this every session)
- Explore before you code: read the relevant files first.
- After any change, run it and show Ran/Saw proof.
- Never touch code unrelated to the task.
- Match the surrounding code style and naming.
- If a test fails, say so with the output. Never claim done without proof.

Drop this in a CLAUDE.md at your repo root - it auto-loads as standing rules every session.

Before writing any code, map the relevant files, functions, and data flow for this task, and list the risks. Then give me your plan in 3 bullets. If the plan is obvious, proceed and report; if one step is genuinely ambiguous, ask that single question first.

Stops the agent from confidently building the wrong thing.

Debug this by forming a hypothesis first. (1) State what you expect to happen and what actually happens. (2) Add a log or check to confirm WHERE it breaks. (3) Only then propose a fix. Do not guess-and-change. Show me the evidence at each step.

Hypothesis-driven beats shotgun edits that introduce new bugs.

Break this task into independent sub-tasks. For each piece that does NOT touch the same files, spawn a subagent to do it in parallel, then combine the results and resolve any conflicts. Tell me what each subagent did. Never parallelize edits to the same file.

Parallelizes the independent work without agents stepping on each other.

Before you start, restate my goal in one line and list the 3 most likely ways you could get this wrong. Then design the work to avoid those 3 specifically. If avoiding one needs my input, ask that single question now, before generating anything.

Kills the repeated do-over by surfacing the misread up front.

Stage the changes, commit with a message that explains WHY not just what, and push. Before pushing: confirm the build passes and show me a one-line diff summary. Never push if anything is red.

A safe one-liner to commit and push without breaking the branch.