The official Opus 5.5 playbook: hand over the whole task, define 'done' first

What the source published

The guide opens by saying Opus 5.5 works well with the way you already use Claude, with three differences. It keeps going on long, multi-part work better than its predecessor — its biggest gains are on multi-step jobs, and early testers had it run coding tasks for hours with little oversight. It reports plainly what it did, what it found and what it needs from you. And it thinks before every reply, deciding for itself how much thinking a reply needs.

The first recommendation follows directly: hand over the whole task in one message. Name the finish line, like 'the tests pass' or 'every endpoint is migrated', and say when it should stop and ask. The worked example migrates payment endpoints to a new client: done means every endpoint uses the new client, the old client is deleted, and the test suite passes — and it should stop and ask only if a test fails for a reason it cannot explain. With a clear finish line, the model knows when it is done.

The second recommendation is to remove 'think carefully', 'think step by step' and similar lines from prompts and saved instructions. The model already thinks before it replies, and asking again does not add thought; in Anthropic's testing in a chat product, removing such a line made replies start sooner with no clear drop in quality. For a quick answer to a simple question, say 'answer directly'; to change how much it thinks in Claude Code, change the effort setting instead.

Sources: [1] [2]

Try it: brief your first long task this way

1. Clean out the old lines first: delete every 'think carefully' and 'step by step' from your prompts and saved instructions, and for simple questions just write 'answer directly'.
2. Write the whole task as one message: the job itself, the definition of done, the hard conditions that must hold, and the only situations in which it may stop and ask you — then let it run.
3. Put a stopping rule in your project's CLAUDE.md: steps that do not need your input should proceed, status notes ride along with the next action, and it stops only when it cannot continue without you or before destructive actions such as deleting data, force-pushing, or changing anything outside the repository.
4. Add to a running task instead of restarting: in Claude Code, type the follow-up and press Enter while it works — for example, 'also keep the old endpoint names as aliases'.
5. For a large audit or migration, have it split the work across subagents, one per service or area, checking each report's evidence before accepting it, and finish with one table of what is affected and the evidence.
6. Have it keep the task list in a file, such as TASKS.md, ticking items off as it goes — long runs fill the context window and older turns get summarized, but a checklist in a file survives and shows progress at a glance.

Sources: [1] [3]

The full picture: checking results and the app-side tips

When a long run ends, read what it needs from you first — an open decision or a change awaiting approval — then read the rest of the summary. You can fix the summary's format in CLAUDE.md, for example ending every run with three headings: Blocked on me, Changed, Found. For code, ask it to review the diff before a person does, listing only problems it would block the merge for, each with file and line, why it is wrong, and how to show it fails; one early tester found that at its lowest effort it caught more bugs than the previous model at high effort, with fewer false alarms. For research and analysis, add a line asking it to mark anything it could not confirm and say where it looked.

In the Claude apps, check the model picker says Opus 5.5, then use its stronger reading skills directly. Attach the chart, diagram, screenshot or slide itself instead of retyping numbers: this generation reads images more accurately, especially meaning that depends on position — which boxes an arrow connects, what changed between two versions of a diagram, or when a meeting starts and ends in a calendar screenshot. Give it a long plan, report or deck and ask it to find contradictions in numbers, dates and names, quoting each problem and its location; in testing it caught a date falling on the wrong weekday and a chart that did not match a deck's numbers. When you want a spreadsheet or document, ask for the finished file rather than an outline. And if follow-ups in a long chat feel slow, add a project instruction that earlier answers are settled and should not be revisited unless asked — but leave it out of long-analysis projects, where a later step may expose an earlier mistake.

Sources: [1]

Key takeaways

• Ask differently: one message with the whole task, the finish line, and the stop-and-ask conditions — then leave it alone.
• Delete 'think hard' lines: the model thinks before every reply anyway; say 'answer directly' for quick answers and use effort to tune thinking.
• Run long work with three supports: a stopping rule in CLAUDE.md, subagents fanning out in parallel, and a task list kept in a file.
• Check in order: what it needs from you first, then a self-review that lists only merge-blocking problems, with anything unconfirmed explicitly marked.
• In the apps, attach originals instead of retyping numbers, ask for contradiction checks on long documents, and request the finished file when you want one.

Sources: [1]