Long sessions drift
Short sessions rarely go wrong. Long ones (a migration, a big feature, a gnarly debugging hunt) accumulate stale context, half-abandoned approaches and small misunderstandings. Steering is the skill of keeping a long session pointed at the goal.
Interrupt early, redirect precisely
The moment you see Claude heading the wrong way, press Esc. The current turn stops and the work so far is kept. Then redirect with specifics:
stop, don't refactor the whole module. only change the parsing function and keep its signature.An early nudge costs seconds. A late one costs a rewrite.
Rewind: a time machine for your session
Claude Code takes checkpoints as it edits. Press Esc Esc with an empty prompt (or type /rewind) to open the rewind menu, pick an earlier point, and restore:
- the conversation only (keep the code, rewind the chat),
- the code only (keep the chat, undo the edits), or
- both.
Rewind restores files that Claude changed with its edit tools. Changes made by shell commands (a migration script, rm, a code generator) aren't captured. That's one more reason to work on a git branch and commit at good checkpoints.
If you've corrected Claude twice on the same thing and it's still wrong, stop correcting. The context is now full of failed attempts. Rewind to before the first attempt (or /clear) and write a better prompt that includes what you learned.
Directing compaction
In a long session, compaction is inevitable. Auto-compaction will summarize for you, but you'll get a better summary by compacting at a good moment with explicit focus:
/compact keep: the agreed migration plan, files already migrated, the 3 remaining failures and their error messages. drop: exploration of the old ORM.Good moments to compact: right after finishing a phase, before starting the next, or when /context shows you're past about two-thirds full.
Hands-on steering vs. goal-driven runs
| Style | How it works | Best for |
|---|---|---|
| Hands-on | You prompt, review, nudge, repeat | Ambiguous work, design decisions, learning a codebase |
| Goal-driven | You set a completion condition with /goal and Claude keeps working across turns until it's met | Well-defined work with an objective finish line |
/goal all tests in tests/billing pass and `pnpm tsc --noEmit` reports no errorsA goal works best when "done" is checkable: tests pass, the build is clean, a benchmark meets a threshold. "Make it better" isn't a goal. "p95 latency under 200ms in bench/api.ts" is.
- ⋮⋮Press Esc to stop the current turn
- ⋮⋮Open the rewind menu with Esc Esc
- ⋮⋮Restore code and conversation to before the bad approach
- ⋮⋮Write a sharper prompt that includes what you learned
Check your understanding
What does rewind NOT capture?
After two failed corrections, the best move is usually:
Which is a good /goal?
When is a good moment to run /compact manually?