Claude Opus 5.5 User Guide: From Assigning Tasks to Reviewing Results

When using Claude for large code changes or complex work, many people break tasks into small incremental steps, repeatedly asking "continue?", and adding instructions like "think carefully." These habits were originally meant to keep tasks from going off course. But with Opus 5.5, which is far more capable of sustained execution, this approach can end up fragmenting work that could have been completed in a single coherent run.

Anthropic's user guide observes three key shifts: Opus 5.5 is better at driving multi-step long runs than previous generations; it decides on its own how much to think before each reply; and when it finishes, it explains much more clearly what it did, what it found, and what still needs your attention. Rather than micromanaging every step along the way, it is far more effective to clarify the entire task, the definition of done, and the conditions under which it must stop right at the start, inject genuinely new requirements while it runs, and verify the evidence and artifacts after it finishes.

Giving it free rein has its limits: irreversible actions like deleting data, force-pushing, or modifying files outside the repository still require strict pause rules and permission confirmations. Even when the model reports that it is done, you must still inspect the tests, code diffs, and unconfirmed items.

If you want an overview of Opus 5.5's capabilities, performance, and pricing first, you can check our previously published model overview; this guide focuses on applying it to real-world tasks.

1. Core Mental Model and Three Things to Try First

Mastering Opus 5.5 begins not with acquiring more elaborate prompting tricks, but with eliminating inefficient manual interventions. In your first session with it, Anthropic recommends trying these three things first:

1. Hand over the whole task and define the finish line: In a single message, state the complete task objective, specify what “done” looks like, and define the conditions under which it should stop and ask questions. Then let it work autonomously.
2. Delete “think carefully” and related prompts: Opus 5.5 already has built-in deep thinking before every reply and assesses the required compute on its own. There is no need to manually prompt it to think hard.
3. When a long run ends, read what it needs from you first: Once a lengthy run concludes, look first at any blockers or decisions the model flagged for you. Only after confirming there are no blocking items should you read through the full summary of changes.

2. How to Ask: Organizing Prompts and Boundary Constraints

Before launching a task, you need to adjust habits developed with older models. According to Anthropic, the biggest improvement in Opus 5.5 over its predecessors is on multi-step complex work (such as carrying a refactoring through a large codebase until all tests pass).

1. State the Full Scope, Finish Line, and Stop Conditions All at Once

• What to do: Organize the entire task into a single prompt and hand it over at once. Explicitly name the finish line (what “done” looks like), and specify under what circumstances it must stop and ask you questions.
• Why it works: Early testers reported that Opus 5.5 can run programming tasks for hours with little oversight. Giving it a clear finish line allows it to autonomously troubleshoot and iterate until the goal is met; a clear finish line also gives you explicit criteria to verify whether it actually finished afterwards.
• Practical example (for Claude Code):

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.

Structure breakdown:

1. Whole task: Migrate payment endpoints from the old client to the new one.
2. Definition of done (Done means): Every endpoint is wired to the new client, the old client code is completely deleted, and the test suite passes.
3. Stop condition (Stop and ask): Stop and ask only if a test fails for an unexplainable reason.

These three criteria correspond to three verifiable results: confirming each endpoint uses the new client, confirming the old client is no longer in the codebase, and finally checking the test suite execution results. If a test fails for an unexplainable reason, the model should hand over the failure symptoms and the leads it investigated, rather than treating "code modified" as done.

Figure A: One message clarifying the whole task, finish line, and stop conditions (Anthropic official example)

2. Completely Remove “Think Hard” (think carefully / think step by step)

• What to do: Remove phrases like think carefully and think step by step from your prompts, system instructions, or project configuration presets.
• Why it works: Opus 5.5 features built-in deep thinking and automatically determines how much to think before generating a reply. Anthropic notes that in a specific test within a chat product, removing a "think carefully" instruction allowed replies to start sooner with no clear drop in quality; this was a specific test observation and does not mean all tasks will see an identical speedup.
• How to control thinking:
  • If you just need a quick answer to a simple question, say directly in the prompt: Answer directly.
  • In the Claude Code terminal, if you need to adjust overall thinking depth, configure the system effort parameter.

3. Forgot Something Mid-Run? Press Enter to Add Instructions

• What to do: Once a task is running in the terminal, if you suddenly remember a constraint or an omitted detail, there is no need to interrupt the run and start over. Simply type your follow-up instruction into the terminal and press Enter.
• Why it works: Because individual Opus 5.5 runs take longer, the cost of restarting is significantly higher. Claude Code supports receiving supplemental messages while the model is actively working.
• Practical example: While the model is working, type directly: Also keep the old endpoint names as aliases.

4. For Design Tasks: Name the Styles You Don't Want

• What to do: When asking for a webpage, front-end application interface, or presentation asset (Artifact), explicitly list the specific design patterns and visual habits you want omitted.
• Why it works: With no design guidance, Opus 5.5 tends to fall back on a few default styles. Giving only a broad instruction (like “avoid a generic look”) usually just mechanically swaps one default style for another. A specific negative exclusion list works noticeably better.
• Practical example:

Build a personal website with placeholder content.
Don't use a cream or off-white background, italic accent words in
headings, numbered "01 / 02 / 03" section labels, monospace labels, or
pill-shaped buttons.

Prompt breakdown: Create a personal website with placeholder content while explicitly ruling out cream or off-white backgrounds, italic accent words in headings, "01 / 02 / 03" section labels, monospace labels, and pill-shaped rounded buttons.

• Follow-up: Look at the alternative styles it chose. If the new style is still not what you want, add the newly observed traits to the exclusion list and generate again.

3. Steering Long Runs in Claude Code

In the Claude Code terminal, long runs can sometimes report progress too frequently or hesitate before taking critical actions. Setting explicit rules and permission prompts ahead of time keeps long runs progressing smoothly.

1. Configure CLAUDE.md: Set Clear Rules for Pausing and Proceeding

Terminology note: CLAUDE.md is a project instruction file that Claude Code reads, ideal for storing persistent working conventions across a project.

• What to do: Write brief rules in your project's CLAUDE.md defining when the model is allowed to proceed autonomously and when it must pause to ask you.
• Why it works: Opus 5.5 tends to keep users posted during long tasks. Without constraints, it sometimes stops just to report: stating the next step without executing it, asking “Want me to continue?”, or listing choices that don’t actually block progress. Making stop conditions clear reduces unnecessary interruptions.
• Recommended configuration (place in project root CLAUDE.md):

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.

Rule breakdown:

• Keep going: When a step does not require human input, proceed directly to the next action; combine your current status notes and next action into the same message.
• Stop and ask: Stop and ask only when unable to continue without human input, or before destructive actions (deleting data, git force-push, or modifying files outside this repository).

Figure B: CLAUDE.md rules defining when to advance automatically and when to pause for confirmation

• Pause and permission considerations:
  • If a run occasionally stops and asks Want me to continue?, simply reply continue. If this happens too frequently, the rule above needs to be added or reinforced.
  • When granting the model greater autonomy with fewer stops, you must keep terminal permission prompts enabled for destructive commands, ensuring high-risk operations still require manual approval before execution.
  • Pair programming variant: If you prefer hands-on pair programming, you can specify the opposite interaction style in CLAUDE.md: "Give a one-line plan before starting and a short summary at the end." Opus 5.5 follows either convention reliably.

2. Large Audits and Migrations: Split Across Subagents and Scrutinize Evidence

• What to do: For audits, migrations, or code reviews across large codebases, instruct Opus 5.5 to invoke multiple parallel subagents, with the primary model responsible for aggregation and evidence verification.
• Background and mechanism: Early testers had Opus 5.5 autonomously coordinate parallel subagents to handle lengthy code audits and migrations, with the main agent breaking down and distributing tasks while subagents independently explored specific directories or services.

Audit every service in services/ for the retry bug in the linked issue.
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.

Prompt breakdown: Audit all services in the services/ directory for the retry bug referenced in the linked issue. Assign each service to its own subagent. When a subagent reports back, verify its supporting evidence before accepting the finding. Format the final output as a three-column table: service name, affected (yes/no), and specific evidence.

Figure C: Tasks distributed to subagents, primary agent verifying evidence before aggregating output (the four subagents in the diagram are illustrative)

3. Keep Task Lists in a File to Survive Context Compression

• What to do: For tasks expected to take a while, instruct the model to maintain a checklist in a local file (such as TASKS.md) and update completion statuses as it goes. Check task progress by reading this file directly rather than scrolling through terminal history.
• Why it works:

  Mechanism explanation (Context window compression): Long runs produce substantial terminal output and code search results that fill the context window, after which Claude Code automatically summarizes and compresses earlier conversation turns. Checklists living only in terminal scrollback can lose details during compression, but a checklist saved to a local disk file survives, allowing both you and the model to see what is done and what remains at any time.

• Practical prompt: Keep a checklist in TASKS.md. Tick each item when it’s done, and add anything new you find.

4. How to Inspect and Review: From Blockers to Code and Analysis

When a long run completes, there is no need to blindly read through voluminous execution logs. Follow these steps to review results efficiently:

1. Look for What Needs Your Attention First (Blocked on Me)

• What to do: When a long run finishes, look first at the most prominent part of the report: identify items where the model is currently waiting on a decision from you (such as choosing between technical approaches or approving an architectural change). Once you verify there are no blockers, read through the body of the changes.
• Why it works: One of Opus 5.5's defining characteristics is its plain-language reporting style; its summaries clearly distinguish between what it did, what it found, and what it needs from the user.
• Format enforcement tip: You can enforce this final summary structure in your project's CLAUDE.md, for instance by adding: End every run with three headings: Blocked on me, Changed, Found.

2. Have the Model Self-Review the Diff / PR Before Human Review

• What to do: Before submitting code to human colleagues for review, ask Opus 5.5 to run a targeted review of the branch's code diff or pull request.
• Feedback and advantages:

  Tester feedback: One early tester noted that Opus 5.5 at its lowest compute effort caught more bugs than the previous Opus 5 at high effort, with fewer false positives. Additionally, because its explanations use plain, accessible language, PR descriptions generated by it are easier for humans to review.

• Practical 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.

Prompt breakdown: Compare the diff between the current branch and main. List only issues serious enough to block the merge. For each issue, specify: the file and line number, why it is wrong, and how to demonstrate that it fails.

3. Research and Analysis: Explicitly Require Flagging Unconfirmed Findings

• What to do: When conducting codebase research, market analysis, or technical evaluations, proactively instruct the model to highlight blind spots and unverified items.
• Why it works: In serious engineering and research contexts, explicitly stating what could not be found or verified ensures readers know which conclusions still require independent validation.
• Universal suffix: Append to your request: Mark anything you couldn't confirm, and say where you looked. This requirement works equally well in Claude research reports and Claude Code.

5. Handling Everyday Work in Claude Apps

Before working in Claude apps (web or desktop), check the model selector to confirm that Opus 5.5 is currently selected.

1. Share Charts or Interfaces Directly via Screenshot—Never Manually Transcribe

• What to do: When dealing with architecture diagrams, flowcharts, data tables, or calendar screenshots, attach them directly as images instead of spending time transcribing numbers or describing topologies.
• Why it works: According to Anthropic, Opus 5.5 reads charts, flowcharts, and screenshots more accurately than Opus 5 without needing extra processing steps. It also better understands spatial relationships, such as which boxes an arrow connects, what changed between two versions of a diagram, or when a meeting starts and ends in a calendar view.
• How to ask: Attach the image and ask a specific question, such as: Which of these services call the billing API directly?

2. Audit Long Documents and Plans for Self-Contradictions

• What to do: Feed in lengthy project plans, evaluation reports, or slide decks, and ask it specifically to search for internal contradictions.
• Why it works: Opus 5.5 pays greater attention to detail than prior Opus models. Anthropic noted that in official testing, it caught a date falling on the wrong weekday in a long planning thread, and spotted discrepancies between slide deck charts and body text numbers.
• Practical prompt: Check this deck for anything that contradicts itself: numbers, dates and names. Quote each problem and say where it is.

3. Request Finished Files Rather Than Rough Outlines

• What to do: When you need data tables, schedules, or documentation, ask directly for an exportable, finished spreadsheet or complete document rather than settling for an outline.
• Why it works: Anthropic notes that spreadsheets and documents produced by Opus 5.5 require less manual editing before sharing than those from Opus 5 (final verification based on intended use is still recommended).
• Practical prompt: Make this a spreadsheet I can share: one row per vendor, with columns for cost, contract end date and owner.

4. When Follow-ups Slow Down in Long Chats: State That Answers Are Settled

• What happens: In extended multi-turn conversations, when you ask a short follow-up question, the model's thinking time can sometimes feel unusually long. The source notes that one possible reason is that while pondering a short follow-up, the model goes back over earlier answers.
• Solution: Add a settlement statement in project custom instructions:

Once you have answered something, treat that answer as done. Focus on
what I'm asking now, and don't go back over an earlier answer unless I
ask about it or point out a problem with it.

Instruction breakdown: Once you have answered a question, consider that conclusion finalized. Focus strictly on the current question and do not revisit or re-examine earlier answers unless explicitly instructed to do so or when an error is pointed out.

• Exception caveat: Do not include this rule for complex, multi-stage syntheses or research tasks, where later steps often need to dynamically correct deviations uncovered in earlier ones.

6. Safety Flags and Speed Controls

According to Anthropic, Opus 5.5 is the first Opus model to launch with Fable-level biological and cybersecurity safeguards. While protecting critical safety boundaries, these high-standard safeguards may occasionally flag legitimate engineering operations. Understanding the triggering mechanisms helps avoid getting blocked.

1. Switching Mechanism: What Happens When a Flag Triggers?

• What happens: In Claude apps and Claude Code, most flagged messages cause the session to automatically switch to an older model to continue the conversation.
• Allowed vs. restricted scope:
  • Explicitly permitted tasks: Searching for security vulnerabilities in source code is compliant and explicitly permitted.
  • General Q&A: Everyday health and educational questions generally remain usable.
  • False positives and tuning: Official guidance notes that current safety mechanisms may occasionally misjudge legitimate engineering workflows; teams are actively tuning them to reduce false flags.

2. Concrete Steps When Switched

In Claude Apps (Web / Desktop):

• Interface notice: You will see a notification beginning with Switched to..., indicating that the current answer was generated by an older model, and subsequent turns will stay on that older model by default.
• Actions to take:
  1. Switch back: Manually click the model selector at the top of the interface and reselect Opus 5.5. Important note: The safety scan evaluates the entire conversation history, uploaded attachments, and search results; if the flagged content remains in chat history, it may easily trigger another switch. In such cases, starting a new chat prevents older messages from triggering repeated flags.
  2. Disable automatic switching: If you prefer to decide yourself rather than having the system switch automatically: go to Settings → Capabilities → toggle off Switch models when a message is flagged. Once disabled, triggering will display a paused card with explicit options for you to choose from.

In Claude Code (Terminal CLI):

• Interface notice: The terminal outputs a notice indicating it has switched to an older model and continues the session under that model.
• Actions to take:
  1. Run /model to manually switch back to Opus 5.5.
  2. Press Esc twice (Esc Esc) to quickly recall and edit your last sent message, then resubmit.
  3. Run /config to adjust the global setting for whether to automatically switch models when flagged.
  4. If you confirm a legitimate code operation was wrongly flagged, run /feedback to report the false positive.

3. Do Not Ask It to Reproduce Internal Reasoning in Replies

• What to do: Remove requests to "reproduce internal reasoning in the reply" from your prompts, system configurations, and project instructions.
• Underlying reason: Requesting the reproduction of internal reasoning in the reply falls into one of the categories that can trigger a flag, and such requests may be declined directly by the model.
• Alternative approach: If you need to understand its decision rationale, ask for a concise summary explanation, such as: Explain why you chose this approach in three sentences.

4. Fast-Paced Interactive Work: Enable Fast Mode as Needed

• When to use: When collaborating in Claude Code with rapid back-and-forth interaction—where you read each response before asking the next question—consider turning on Fast Mode.
• Technical background and pricing: Fast Mode is available at launch as a Research Preview. It runs the exact same complete Opus 5.5 model, but text arrives faster. Note that this mode requires the account to have extra usage enabled, and costs more per token than standard mode.
• How to enable: Type /fast in the Claude Code terminal to turn it on or toggle it.

End-to-End Self-Check Checklist

Run through this checklist before embarking on your next long development run or complex task:

Figure D: End-to-end onboarding and execution checklist for Opus 5.5

1. Asking and Preparation

• [ ] Does the prompt define clear criteria for what “done” looks like (Done means...)?
• [ ] Have redundant prompts like "think hard" and "step by step" been completely removed from prompts and instructions?
• [ ] For design and front-end tasks, is there a specific negative exclusion list of unwanted styles?
• [ ] For charts, flowcharts, or calendars, are original screenshots attached directly rather than manually transcribed?

2. Long Runs in Claude Code

• [ ] Does CLAUDE.md define rules for when to keep going and when to stop before destructive actions?
• [ ] Are manual permission prompts for destructive commands kept enabled?
• [ ] For large-scale code reviews or migrations, is the model instructed to split work across parallel subagents?
• [ ] Is the model instructed to maintain its progress checklist in a local file (such as TASKS.md)?

3. Reviewing and Checking Results

• [ ] After a long run completes, did you first review the items flagged as waiting on human action (Blocked on me)?
• [ ] Did you have the model run an initial self-review pass on the diff / PR before human review?
• [ ] For research or analysis tasks, did you explicitly instruct it to mark findings that were unconfirmed or not found?

4. Safety Flags and Recovery

• [ ] Do you know how to switch back to Opus 5.5 after a flag occurs (via the model selector or /model)?
• [ ] Have you configured whether to automatically switch models upon being flagged in settings or /config according to your workflow?
• [ ] Have you confirmed that prompts do not ask the model to reproduce internal reasoning in the reply?