Keeping a long session on course
Long tasks are a different game from quick ones: it comes down to two habits — scope the work before Claude starts (plan mode), and steer it while it runs.
Key concept · Compact, rewind, goal, loop, worktrees
Compaction summarizes the conversation to free context — steer it by adding focus after the command (/compact Focus on the --version flag) so it keeps what matters. Rewind (double-tap escape) returns to a checkpoint; options include restore code / conversation / both, and summarize from/up to here. For autonomy: /goal sets a completion condition Claude works toward until a fast evaluator confirms it (the evaluator only reads the transcript, so the condition must be checkable from output; /goal clear cancels); loop runs a prompt on an interval to react to external state like a CI run. For parallel agents, worktrees give each session its own file tree so they can't clobber each other (a .worktreeinclude file copies needed git-ignored files into each).
Rules Claude actually follows
Configuration is how you get consistent behavior without babysitting: a CLAUDE.md that follows, verification skills, the right permission mode, and hooks.
Key concept · Lean config plus enforced checks
Write a lean CLAUDE.md Claude actually follows (short and load-bearing beats long and ignored). Package repeated procedures as verification skills so quality checks run the same way each time. Pick the permission mode that fits the run — from manual approval, to accept-edits, to auto — matching autonomy to risk. And use hooks to enforce rather than hope: a hook fires on an event (a file save, the end of a turn) and can run a linter, type-checker, or test — the exit code decides whether Claude proceeds.
Automate the repeats, then trust the result
The payoff: schedule and offload work, then verify what nobody watched. Routines schedule prompts on Anthropic infrastructure; headless mode runs a job non-interactively (with a JSON result); GitHub Actions bring Claude into CI and code review. The capstone lesson is trusting an unsupervised run.
Key concept · Verify in proportion to how little you watched
The rule: the less you watched, the more you verify. Keep unattended runs in auto mode (the classifier still flags dangerous actions — but never judges whether the code is correct, so your verification bar stays). Then: start with the diff, not the summary — run /code-review, then read git diff yourself (a tidy summary can hide a file you didn't expect it to touch). Turn tests into a gate, not a promise — wire a stop hook that runs tests and refuses to end the turn on failure, and a post-tool-use hook that lints/type-checks after edits; a hook exiting exit 2 feeds the failure back so Claude fixes it. And get a cold second opinion from a fresh subagent reviewer that never saw how the code was built.
Finally, plugins package your steering, config, and verification setup so a whole team installs the same trusted workflow.
Chapter 15 quiz
Fourteen questions on steering, configuring, automating, and verifying. Answer first, then expand Show answer.
Part A · Multiple choice
The two habits for long sessions are:
- A Scope the work before Claude starts, and steer it while it runs
- B Type faster, hope harder
- C Never plan, always regenerate
- D Avoid long sessions
Show answer
A.
How do you steer what a /compact keeps?
- A Add focus instructions after the command
- B You can't
- C Delete the transcript
- D Restart the session
Show answer
A. e.g. "/compact Focus on the --version flag."
What does Rewind (double-tap escape) do?
- A Returns to a checkpoint — restore code, conversation, or both
- B Deletes the repo
- C Runs the tests
- D Opens settings
Show answer
A. Every user prompt creates a checkpoint.
A key constraint of /goal is that the evaluator:
- A Only reads the transcript — the condition must be checkable from output
- B Can inspect your mind
- C Runs forever
- D Ignores the condition
Show answer
A. e.g. "all tests in src/billing pass."
Why run parallel agents in worktrees?
- A Each gets its own file tree so sessions can't clobber each other
- B They're cheaper
- C They share one context
- D No reason
Show answer
A. A .worktreeinclude copies needed git-ignored files in.
The rule for verifying a run is:
- A The less you watched, the more you verify
- B Always trust the summary
- C Never verify
- D Verify only short runs
Show answer
A.
In auto mode, the classifier:
- A Flags dangerous actions but never judges whether the code is correct
- B Guarantees correct code
- C Replaces your review
- D Disables tests
Show answer
A. Your verification bar stays.
When verifying, you should start with:
- A The diff (/code-review, then git diff), not Claude's summary
- B The summary alone
- C The commit message
- D Nothing
Show answer
A. A clean write-up isn't proof of clean code.
Part B · True or false
A hook exiting with exit 2 feeds the failure back to Claude to fix.
Show answer
True. And it fires every run, not just when you remember.
A stop hook can refuse to end the turn when tests fail.
Show answer
True. Turning tests into a gate, not a promise.
Asking the same session that wrote the code to review it gives the strongest feedback.
Show answer
False. Get a cold second opinion from a fresh subagent with no memory of how it was built.
A lean CLAUDE.md that Claude follows beats a long one it ignores.
Show answer
True.
Part C · Short answer
Name three ways to steer a long session.
Show answer
Any three: plan mode, directed compaction, rewind, /goal, loop, worktrees.
Give the four moves for verifying an unsupervised run.
Show answer
Read the diff yourself; gate the turn with a test hook; verify headless runs by JSON result and exit code; get a cold second opinion.