A long coding task can lose a requirement when you add a correction, or end with a summary that leaves the next step undone. Keep the current plan in a file, state which work may continue, and ask for a report that separates finished work from decisions waiting on you.
Claude Code educator Duncan Rogoff demonstrates these habits in How Anthropic Engineers Actually Use Claude Opus 5.5. His walkthrough draws on Addy Osmani’s Anthropic playbook. This guide applies their advice to an active coding task. For the initial request, start with Give your coding agent a finish line.
01Correct the active task
In Claude Code, type a follow-up and press Enter while the agent works. The playbook documents this way to add a requirement mid-run; Rogoff demonstrates the idea at 3:37.
Make the relationship to the original request explicit. This original follow-up adds a compatibility requirement:
Continue the client migration. Keep the old endpoint names as aliases because existing callers still use them. Add tests that call those old names and update TASKS.md before continuing. The requested result is still a local patch ready for review.
Check that the next update includes the correction. If the new requirement conflicts with work already done, ask the agent to identify the affected files before proceeding.
02Save progress with evidence
Rogoff recommends a task list saved in a file. The playbook names TASKS.md: a file remains available when Claude Code summarizes older conversation turns. Ask the agent to update the file as it works and reread it when resuming.
Our recommendation is to record evidence beside each completed item:
| Item | Record in the task file |
|---|---|
| Code changed | Affected paths and the requirement addressed |
| Check completed | Command or observed behavior, plus its result |
| Check blocked | What could not run and what access or input is missing |
| New requirement | The correction and the work it affects |
A checked box is a progress claim. Compare it with the files and check output. Guardrails for hours-long agent runs covers saved context and fresh review in more depth.
03Name the stops you want
The playbook recommends a short CLAUDE.md rule to prevent status reports from ending work that can continue. Keep permission prompts enabled for destructive commands. Rogoff also makes the boundary explicit:
“stop and ask only when you can't continue without me”
Duncan Rogoff, “How Anthropic Engineers Actually Use Claude Opus 5.5” · 5:40He also names destructive actions and changes outside the repository as reasons to ask. This original rule keeps those limits and specifies the final report:
Continue reversible work already covered by my request. Give progress updates while taking the next available action. Keep TASKS.md current, including corrections, completed checks, and blocked checks.
Ask when a missing decision prevents progress. Ask before deleting data, force-pushing, changing another repository, merging, or deploying. Preserve existing permission controls.
End with decisions needed from me, changes made, checks and their results, and anything unverified. Link the relevant files or evidence.
Put lasting project rules in CLAUDE.md and task-specific requirements in the request or task file. Trim the instructions your model outgrew explains how to test instruction changes while keeping fixed requirements.
04Check the remote handoff
A remote session needs the task, access, and checks required to finish it. Developer Theo adds a worked example in Getting the most out of Opus 5.5, his commentary on the same Anthropic playbook. He moves a coding task to another computer so browser automation can run without interrupting his laptop use.
His request names what the agent may do and when it should ask for help. For your own handoff, specify:
| Handoff detail | What to name |
|---|---|
| Destination | The machine, repository, branch, and approved connection method |
| Required access | Which configuration or credentials may be transferred, and where |
| Working environment | The runtime, test commands, and browser access to verify |
| Local limits | Whether the agent may open windows or control your current machine |
| Blocker | Ask if the destination or required tools fail, before choosing a different setup |
Theo explicitly permits the configuration transfer and invites questions if the move fails. Keep that permission specific to the destination and task. Assume your agent uses every tool it has covers how available tools affect those limits.
Check that implementation continues after setup. Theo discovers that the new session stopped after phase zero, despite receiving a plan with later phases. Our recommendation is to record setup and implementation separately in TASKS.md, then confirm that the receiving session has the full finish condition and approval boundaries.
05Avoid max effort by default
Theo recommends high or xhigh for Opus 5.5 and warns against max effort. In his Skatebench comparison, max used far more tokens and time for a small accuracy gain:
| Reported result | xhigh | max |
|---|---|---|
| Average tokens per response | 338 | About 5,000 |
| Average response time | 6 seconds | 50 seconds |
| Accuracy | 78% | 79% |
These are Theo’s reported results on one benchmark. They support trying high or xhigh first; they do not establish that max is never useful. He uses either high or xhigh in his own work. Compare effort settings on your task using the same completion check, and record quality, time, and token use. Recheck your model choices each release covers that comparison.
For other ways to reduce token use during long runs, use our practical token-saving guide at savetokens.tips. It covers shorter replies, scoped file reads, command-output filtering, and model routing.
06Ask what could break
The playbook recommends reading what Claude needs from you before the rest of its final report. Resolve that decision, then compare the claimed result with the checks you requested.
Theo adds a useful question when returning to an old task: what are the risks of merging this code today? Ask for the failure and its evidence. This original follow-up turns the answer into a review request:
What could break if we merged this change today? For each risk, name the affected behavior, the evidence, and the check that would confirm or rule it out. Separate confirmed problems from unverified concerns. Say which checks could not run and what they need. This is a review request; do not merge.
Give the reviewer the tools needed to test those concerns. Theo names missing hardware, environment variables, and subjective judgments as reasons a claim may remain unverified. Anthropic’s verification guidance recommends checks that return observable results, such as tests or screenshots.
For a large audit, request the division of work explicitly. Theo reports that permission to use subagents can still leave the work unsplit. Name the separate areas to review and require evidence from each. Split big AI tasks into steps and checks covers that division of work.
A second model can provide another review. Theo finds value in switching model families, while acknowledging that reviewers also report problems that do not matter. Treat each finding as a claim to verify against the code and a reproducible failure. Extra reviewers do not establish correctness by agreeing.
Read Addy Osmani’s full Anthropic playbook: Getting the most out of Opus 5.5 in Claude and Claude Code.