# 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.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
That is not right: {{feedback}}

Try a different approach.
{{#keep}}
Keep: {{keep}}
{{/keep}}

Before changing anything:
1. Say in one or two sentences why the previous approach missed this constraint.
2. Describe the new approach and how it meets the constraint.
3. List the edits from the previous attempt that the new approach replaces.

Then {{proceed}}. When you implement it, undo the edits from step 3 and leave everything else as it is.

If the constraint is unclear, or conflicts with another requirement you know about, ask me instead of guessing.

When the change is done, verify it{{#check}} with: {{check}}{{/check}}. If no check is given, use the project's existing tests or build. Show me the command and its result. Do not commit.
```

## Fields

- `{{feedback}}` (required): What is wrong, and the constraint Claude missed. State the reason, not only that it is wrong. A concrete constraint gives the retry something to satisfy.
- `{{keep}}`: What to keep from the current attempt. Optional. Parts of the work that were right and should survive the retry.
- `{{check}}`: How to check the retry. Optional. A command or condition that shows the constraint is met.
- `{{proceed}}`: When to continue. Choose one:
  - wait for my go-ahead before you edit anything (default)
  - go ahead and implement it

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

## 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.

## Related templates

- [Narrow the scope of a change](https://awesomeclaudeprompts.com/prompts/narrow-change-scope/): 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](https://awesomeclaudeprompts.com/prompts/correction-to-claude-md/): 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](https://awesomeclaudeprompts.com/prompts/plan-code-change/): 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.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Course-correct early and often](https://code.claude.com/docs/en/best-practices#course-correct-early-and-often) (Anthropic documentation)
- [Claude Code best practices: Rewind with checkpoints](https://code.claude.com/docs/en/best-practices#rewind-with-checkpoints) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.