Awesome Claude Prompts Unofficial

Course-correct a wrong approach

When Claude Code heads the wrong way, name the constraint it missed and ask for a different approach, with a check that shows the retry meets it.

Task: Course-correct a wrong approach · Other tasks

Fill in the details

State the reason, not only that it is wrong. A concrete constraint gives the retry something to satisfy.

Optional. Parts of the work that were right and should survive the retry.

Optional. A command or condition that shows the constraint is met.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • Claude Code is working on a task and you can see the approach will not work, because it breaks a rule it did not know about.
  • You have already stopped Claude with Esc and want to redirect it in the same session, while the context is still useful.
  • The direction is wrong, not just the size of the change. If the change is right but too broad, use the narrow-scope template instead.

When not to use it

  • You have corrected Claude on the same issue more than twice in this session. The docs suggest running /clear and starting again with a better first prompt that includes what you learned.
  • You want the code exactly as it was before the attempt. Press Esc twice or run /rewind to restore an earlier checkpoint instead of asking Claude to undo by hand.
  • The mistake is one Claude repeats across sessions. Fix it here, then add a rule to CLAUDE.md so the correction is available to later sessions as context.

Why this structure

  • The required field asks for the constraint, not just the verdict. A specific reason gives the retry a clear target, where "that is wrong" leaves Claude to guess again.
  • Step 1 asks why the first approach missed the constraint, which shows you whether Claude understood your feedback before it writes more code.
  • Step 3 asks Claude to name the edits the new approach replaces, and only those are undone, so leftovers from the failed attempt are less likely to stay mixed in with the new work.
  • The continue choice lets you review the new approach before any edits when the task is risky, or let Claude go ahead when the fix is obvious.
  • The final step asks for a check and its output. Seeing the command and result is faster than re-running it yourself, and it shows whether the constraint is actually met.
  • The ask-instead-of-guessing line covers constraints that clash with other requirements, which is a common reason the first approach went wrong.

Example input (fictional)

What is wrong, and the constraint Claude missed
the function signature needs to stay backward-compatible. Other services call parseOrder(input) with one argument.
What to keep from the current attempt
the new input validation helper
How to check the retry
npm test, plus the existing callers in src/legacy/ still compile
When to continue
wait for my go-ahead before you edit anything

Follow-ups to send Claude

  • Add a test that would have failed with the previous approach, so this constraint stays covered.
  • Add a one-line rule about this constraint to CLAUDE.md so later sessions know it from the start.
  • Summarize the approach we settled on and the constraint behind it in the pull request description.

Common mistakes

  • Saying only "that is wrong" or "try again". Without a reason, the retry is likely to miss the same constraint in a new way.
  • Waiting too long to correct. The further Claude goes down the wrong path, the more edits there are to unwind; stop it with Esc as soon as you notice.
  • Relying on checkpoints to undo shell commands. Checkpoints track Claude's file edits, not changes made through Bash, so use git for those.
  • Narrow the scope of a change: When Claude Code changed more than you asked for, keep the part you want and have it undo the rest, file by file, then show the remaining diff.
  • Turn a repeated correction into a CLAUDE.md rule: When Claude Code keeps making the same mistake, have it write one short, checkable rule into CLAUDE.md, so later sessions start with the correction.
  • Plan a code change before editing: Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.

See all templates

Sources