Guiding the Conversation Mid-Task

The workflow#

Watch Claude as it works. When the direction is wrong, hit Escape, type a one-sentence correction, resume. When only the tactics are imperfect, let it cook and review the diff at the end. When the correction stack has hit three, scrap the session and restart with a sharper opening prompt.

That is the entire workflow. The mechanical part is the Esc → corrected message → Enter rhythm. The judgement part is recognising which of those three states you’re in.

When to reach for it#

This workflow runs in the background of every Claude Code session. Specifically:

• Multi-step tasks where Claude has visible intermediate work (file reads, plan announcements, partial edits) that you can sanity-check before they propagate.
• Long-running operations — refactors, multi-file changes, anything past two tool calls — where catching a wrong turn at minute three is much cheaper than at minute fifteen.
• Unfamiliar codebases where you didn’t have the context to fully specify the task up front and have to refine the intent as Claude surfaces what’s actually there.
• Tasks where the success criterion is fuzzy and you only recognise “yes that’s it” or “no not that” by seeing partial output.

It is not the right pattern for:

• One-shot tasks where Claude reads, decides, and writes in one round. The conversation has already finished by the time you’d intervene.
• Plan-mode sessions — the whole point of plan mode is that you give Claude space to think without interrupting; intervene by editing the plan, not by Escape.
• Headless / non-interactive runs — there’s no live operator to steer; the prompt has to be right at submit time.

Step-by-step#

The mechanics first, then the judgement.

1. Watch, don’t read the diff#

Keep one eye on the live output while Claude works. You’re not reading every line; you’re scanning for direction signals. Three patterns to watch for:

• File reads. What’s Claude looking at? If it’s reading auth.py when you asked about a logging bug, the direction is already wrong.
• Plan announcements. When Claude says “I’ll do X, then Y, then Z” before tool calls, that’s the cheapest course-correction window — interrupt while it’s still words, not diffs.
• The first edit. If the first concrete file edit goes against your intent, every subsequent edit will compound that mistake. Interrupt before the second edit.

2. Decide: interrupt or let it cook#

The heuristic that holds up:

• Wrong direction → interrupt. Different file, different concept, different shape of solution than you wanted. Don’t wait — the cost of stopping is one Escape; the cost of letting it finish is reading and rejecting the whole diff.
• Imperfect tactics → let it cook. Right direction, slightly clunky implementation. Let it finish, then iterate on the diff. Mid-stream corrections to tactics tend to confuse more than they help.
• Genuine ambiguity → ask. Sometimes Claude’s choice is reasonable but you have an opinion. Interrupt with the constraint, not the override: “Wait — keep the existing helper, don’t write a new one. Continue.”

3. The Escape rhythm#

The mechanical sequence:

[Claude is editing file A]
You: <Esc>                              # interrupt
Claude pauses; the prompt is yours again.
You: "Wait — leave file A alone. The bug is in file B's caller, line 142.
      Trace it back from there." <Enter>
Claude resumes with the corrected scope.

The correction message should be the one sentence Claude needed before the wrong turn. Not a re-prompt of the entire task; just the missing constraint or the right pointer.

4. Three corrections is the limit#

Past three corrections in one session, the model’s context is now half-prompt, half-correction, and the cumulative drift makes everything noisier. The right move at correction four is:

1. Note what the initial prompt should have said (the third correction is your missing spec).
2. Scrap the session (/clear or start fresh).
3. Re-prompt with the missing context baked in.

This feels like waste — you’re throwing away the work-in-progress. It isn’t waste; the next 30 minutes will be much smoother than the previous 30 were.

5. The “wait, also do X” question#

Mid-task scope expansion is a separate trap. Two rules:

• If the addition is small and adjacent, queue it: “Finish what you’re doing, then also fix the same bug in helpers.py.” Claude will batch.
• If the addition is a different concept, hold it for after. Side-quests mid-task pollute the conversation with two threads and produce neither cleanly.

A side-quest worth its own session is worth its own session.

Anti-patterns#

Common ways to mis-steer:

• The narration interrupt. Hitting Escape just to react (“nice, that looks good”) without a correction breaks Claude’s flow without adding signal. Save reactions for the end-of-turn summary.
• Restating the original prompt. When you interrupt, don’t paste the whole task back — Claude already has it. Just add the missing constraint.
• Correcting tactics, not direction. “Use a Map instead of an object” mid-edit usually costs more than it saves. Let the implementation finish; refactor in a second pass if it matters.
• The pile-up correction. Three sentences of corrections in one Escape: “no, the other file, and also rename the function, and also add a comment.” Pick one. The other two are next-turn fodder.
• Refusing to scrap. Past four corrections, sunk-cost makes you want to keep going. The session is poisoned; restart is cheaper than recovery.
• Mid-task plan-mode requests. “Enter plan mode” mid-task means starting over. Either let the current task finish, or hit Escape and re-prompt cleanly with plan mode from the start.

Evaluation#

How to tell if your mid-task guidance is working:

A productive Claude Code session looks like: one specific opening prompt, one or two mid-task interrupts to add missing constraints, one final review and commit. Sessions that look like ten corrections and three restarts mean the opening prompt was the actual problem — fix that next time. See Advanced Prompting Strategies for the upstream fix.

Related workflows#

• The Conversation Loop — the loop you’re steering. Understanding it makes the interruption mechanics feel natural.
• Advanced Prompting Strategies — the upstream fix. Most mid-task corrections trace to under-specified opening prompts.
• Plan Mode — the alternative to mid-task steering: design before doing. Plan mode is steering moved to before the task.
• Conversation-Driven Development — the workflow this pairs with. Conversation-driven dev is the broad pattern; mid-task guidance is how you actually run it.
• Long-Running Sessions and Context Management — when sessions get long, mid-task steering is what keeps context from polluting. Read alongside.