Repair prompts: getting out of a bad turn without starting over

The bad turn, and the two ways out that don't work

So, one of the most typical scenarios during live sessions is that we ask Claude to do sth and it seems it's understood, we run another command and it seems like it's getting it etc, but then the diff starts becoming bigger and bigger and we see that actually it's got the direction wrong. This is the type of situation in which users often say the model "goes off the rails" after 10 prompts. Ofc it's not the model's fault, this is just how we usually communicate, and in such a scenario there are two typical instincts people have which both are not ideal:

• The first one is to repeat what you've said more aggressively. Like if you're trying to make sure it includes some middleware for example, so you keep saying it a few times and it keeps agreeing, and then you run the command and see that once again, it's not using it. That's very much how users feel when they say the model is ignoring them, but in fact it's not about that — it's just that despite you saying it needs to use this middleware, Claude still assumes it doesn't, so it acts on that and keeps acting on it in every turn

• The second instinct is to just discard the session and start a new one with a more elaborate prompt. Sometimes it works but often it doesn't, because you lose the context of files it's already familiarised itself with, the fact that you've already made it amend sth once so you know it can be done, or some code that worked before the turn but doesn't work anymore after it. It's also very common that people fall into the same wrong assumption again in the new session

So what we usually recommend in such scenarios is to write a repair prompt — not a more aggressive instruction and not starting from scratch; a repair prompt is the middle ground between these two extremes, it lets you avoid the bad turn without losing the valuable context from earlier parts of the session. Compared to just creating a new session, it's much faster (in our experience it takes around a minute, compared to starting a completely new session)

Three moves, and which one fits

If you find yourself in such a situation there are 3 moves you can do:

• Repair prompt — this is the one mentioned above and usually what we recommend; use it if you feel like everything it did earlier is good but just this turn was off. Like if it was meant to update a file but used a different one, or you had a good plan for it but it made a wrong move in the last step; this way you won't lose anything and it's the least "aggressive" of the options

• Rewind — use it when you feel like it got some assumptions wrong based on the context (eg you mentioned some file and now it thinks it's important); in such a scenario its later instructions are based on these assumptions, so just saying what you meant won't work as it'll fold your new words into that same reasoning chain. So with rewind, we just roll back the conversation to before the turn and change the prompt so it doesn't have any of these wrong ideas in the first place. This way you keep the good code but get rid of the bad train of thought

• Restart — the last option is to start a new session; this is the most radical move but sometimes it's necessary if you feel like you haven't framed the task properly, or if the session becomes unusable anyway because it's been going on for too long. We'd say it's not very common, and in most cases the proper framing can be achieved with rewind, but there are scenarios when it's actually the only right move; if any of the above solutions is "cosmetic" compared to starting a new session, this is the one you should go for

It's important to understand that these moves are all about making a choice rather than taking the most aggressive option by default. Very often people ask us which of these moves they should do and we always say it depends; it's a fast selection, not a default to the most radical solution

If you wonder what to choose in a particular scenario, ask yourself these questions:

• Do you see a single specific place where it did sth wrong? If yes, that's when you can use a repair prompt

• Does it keep acting based on some idea despite how you rephrase your instructions? Then it means it has this idea embedded in the context and you need to either roll back or start a new session

• Do you think you could properly frame the task now if you were to start a new session? If not, then you need to start a new one and first focus on framing the task

Anatomy of a repair prompt

Now, let's have a look at what a repair prompt looks like. The most important thing is that it's not about repeating your instruction louder; we need to alter its foundations. There are 5 elements in every repair prompt, the fourth being the most often omitted:

1. Identifying the problem from its perspective — instead of just saying you don't like sth, you point at a specific thing it did or assumed; "I don't like it" is not useful for it, but "you edited auth.py; the change belongs in middleware.py" is

2. Defining the goal as an observable outcome rather than an adjective — instead of saying you want your solution to be more secure, say you want it to return 401 before reaching the handler. It's about translating our thoughts into action; as we covered in the agent loop lesson, adjectives don't work in that regard

3. Specifying what stays — by default it will just rewrite everything on its own, so we need to tell it what we want to keep; saying "keep these tests" for example tells it not to touch them

4. Single concrete step — we need to give it one specific thing to do before it acts on further instructions; that way it's always possible to check if the action is correct before it proceeds with the rest of the prompt

5. Restatement instead of confirmation — if there are multiple things you keep telling it and it keeps missing, don't ask it to just acknowledge them again, ask it to summarise what it should do instead; saying "understood" doesn't mean much in this regard, so it's good to have a restatement (even if it might not be perfect) as the cheapest way to detect it early

So here's an example of a repair prompt we could send if Claude was supposed to update some file but instead updated a different one, and we want it to return 401 before reaching the handler, keep the tests and move only the check (and we don't want it to change anything else), so we tell it where the check should go and what stays and ask it to stop there:

"I see you have updated auth.py, we needed to update middleware.py instead. I'd like it to return 401 before reaching the handler, we can keep these tests and move only the check here, show me the new location and stop before editing anything else"

As you can see, it's longer than saying "yeah, the middleware" twice, but it actually works

The rewind: undo the turn, don't out-argue it

If you go for the rewind, just delete the turn instead of discussing it with the model. It's about the context being polluted, so if it acts on a new instruction based on what you've said after this turn, you're basically having a conversation in which one of the participants is acting under a wrong assumption, and you don't want that, so you remove it. Also, removal works better than argument

So just in case you haven't been using it recently, there are a lot of tools on the market now that come with some rewind functionality; you can check the Academy's undo/rollback reference for more context. If you're using Claude Code for example, you can hit /rewind or double Esc on an empty prompt to see all the messages that have been sent in this session so far. And then there's an option called "Restore conversation", which basically rolls back the chat to a message of your choice and leaves the current code as is, keeping your cursor in the input field with the original prompt so you can modify it and send again

So it's a single feature that encapsulates the whole method; if you go for rewind, just find the last good turn, roll back the conversation to it so the code is intact, change the prompt and send it

The only thing to keep in mind is that rewind works for the chat and for things Claude changes using its own file tools, but doesn't work for bash commands it runs (like rm or mv) or changes made by subagents. It also doesn't include changes made outside of this session. If you need an undo for these scenarios you can use git; there's a lesson, Git as the real undo, in the Reviewing course if you're curious. Rewind is just a local undo for the conversation, not a time machine for the entire disk

The recipe

So whenever you find yourself in a situation where the last turn didn't go well, here's what to do:

1. Stop the run first — it's important to interrupt it before it does more work in this direction; if you're using Claude Code, you can hit Esc to stop the current response or tool call mid-turn (without affecting the completed work). A repair prompt is a bit of surgery, so we need the patient to lie still during the procedure

2. Choose which move to make — repair prompt, rewind or restart; ask yourself these questions before typing: do you see a single specific place where it did sth wrong? Does it keep acting on some idea despite how you rephrase your instructions? Could you properly frame the task now if you were to start a new session? If it's the first scenario, go for a repair prompt; if it's the second one, go for rewind (or restart if the session is generally unusable); if it's the third one, go for restart

3. If you decide to do a repair prompt, write this 5-part instruction — name the problem, define the goal as an observable outcome, tell it what stays, give it one step to act on and ask it to stop; like in the example above

4. If you decide to do a rewind, restore the conversation to before the turn, modify the prompt and send it. If you used bash commands or subagents, make sure to check whether there's anything you need to revert using git as well (rewind doesn't include these)

5. Ask it for a restatement of the goal before it changes anything and point out if the restatement isn't right — one line defining where it should place sth and what stays; it's about pointing at the wrong restatement, not the diff

6. If you see that despite your repair prompt it keeps making the same mistake, it means it must have this idea stuck in the context, so you can either roll back or start a new session. Don't keep re-prompting it

Also, we've prepared a 5-part skeleton and a set of templates for the most common bad turns (wrong location, overreach, error thrashing, ignoring constraints), feel free to keep these visible during your sessions

When a repair prompt is the wrong tool

Finally, we just want to mention that there are also other scenarios that might look similar from the user's perspective but in which a repair prompt is not the right tool:

• The first one is when the context becomes worse — the "after 10 prompts" thing usually means it's not about a single turn but the entire window becoming unusable; you can't resolve it with better phrasing, just summarise and roll back or start a new session. If you want to know how to make sessions generally more productive, check our Context engineering course

• The second one is when the framing is wrong — if you need to send a third repair prompt about the same task, it means you don't need to keep repairing but rather redefine the shape; roll back to your original request and reframe it, or start a new session and frame it properly from scratch. A fourth repair prompt means you should've just rewound

So if you see that despite sending a repair prompt the output doesn't change, it means you need a rewind, not better phrasing