Claude Opus 5.5 playbook: prompts and Claude Code workflows

A day after Claude Opus 5.5 shipped, Addy Osmani published a nine-minute playbook on claude.dev on getting the most out of it — and the through-line is that the habits that squeezed quality out of older models now cost you time. Opus 5.5 thinks before every reply on its own, runs for hours without hand-holding, and reports back more clearly, so prompting it like a fragile intern actively works against you.

This post distills the guide's recommendations into the five moves that matter for working engineers: how to frame a task, what to delete from your saved prompts, how to steer multi-hour Claude Code runs, how to check the result, and the smaller app-side habits — with the guide's own example prompts quoted so you can lift them directly.

Opus 5.5 task framing: say what done looks like

The first recommendation is to hand over the entire task in a single message with an explicit finish line, then let the model run — early testers report multi-hour runs with minimal intervention. The guide's canonical example is worth copying verbatim:

"Migrate the payment endpoints from the old client to the new one. Done means: every endpoint uses the new client, the old client is deleted, and the test suite passes. Stop and ask me only if a test fails for a reason you can't explain."

Two details make this pattern work: "done" is verifiable (old client deleted, suite green), and the escalation rule is explicit. You can also add to a running task mid-flight — type a follow-up like "Also keep the old endpoint names as aliases" while it works instead of restarting the run.

Thinking and effort: retire the think-hard boilerplate

Opus 5.5 thinks automatically before each reply, so "think carefully" and "think step by step" lines are dead weight — Anthropic's own testing found removing them cut response latency with no quality loss. For quick answers, the guide suggests the opposite instruction: "Answer directly." In Claude Code, thinking depth is controlled by the effort parameter, not prompt incantations. The same logic applies to design work: instead of "avoid a generic look" (which swaps one default for another), name the specific patterns you don't want — the guide's example bans "a cream or off-white background, italic accent words in headings, numbered '01 / 02 / 03' section labels, monospace labels, or pill-shaped buttons."

Long runs in Claude Code: stopping rules, subagents, TASKS.md

For extended autonomous work, the guide recommends three mechanisms. First, put stopping rules in your CLAUDE.md so the model knows when to pause versus proceed:

"When a step doesn't need my input, keep going. Put status notes in the same message as your next action. Stop and ask only when you can't continue without me, or before anything destructive: deleting data, force-pushing, or changing anything outside this repository."

Keep permission prompts enabled for destructive commands regardless. Second, split big audits and migrations across subagents and make the model verify their reports: "Give each service to its own subagent. When a subagent reports back, check its evidence before you accept it. Finish with one table: service, affected yes or no, and the evidence." Third, have long runs keep their checklist in a file — context windows fill up and get summarized, but a file survives:

"Keep a checklist in TASKS.md. Tick each item when it's done, and add anything new you find."

Checking Opus 5.5's work: reviews and unconfirmed facts

When a run ends, read the section about what the model needs from you before the summary of what it did — you can standardize this in CLAUDE.md with "End every run with three headings: Blocked on me, Changed, Found." Before human review, run the model's own review pass; Opus 5.5 catches more bugs than Opus 5 at lower effort with fewer false positives. The guide's review prompt:

"Review the diff on this branch against main. List only problems you'd block the merge for. For each one, give the file and line, why it's wrong, and how to show it fails."

For research tasks, add "Mark anything you couldn't confirm, and say where you looked" — it works in Claude research reports and Claude Code alike, and turns silent guesses into visible flags.

Apps, flags, and fast mode: the rest of the playbook

In the Claude apps: attach the actual chart or screenshot instead of retyping data (Opus 5.5 reads diagrams and spatial relationships better than Opus 5), ask it to check long documents for internal contradictions ("Quote each problem and say where it is"), and request the finished file — a shareable spreadsheet, not an outline. In projects with long chats, tell it settled answers are settled so brief follow-ups don't reopen earlier work. If a message gets flagged and the chat switches to an older model, recover with the model picker or, in Claude Code:

One caution from the guide: don't ask the model to reproduce its internal reasoning in the reply — that request itself can be declined. Ask instead for "Explain why you chose this approach in three sentences." And if you live in rapid iterative sessions, fast mode (same model, 2.5x delivery, higher per-token cost) is the one toggle worth paying for. For the launch benchmarks and pricing behind all this, see our Claude Opus 5.5 launch coverage.