You're Prompting Opus 5.5 Wrong (Anthropic's Guide to Mastering Opus 5.5)

Author: Better Stack · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: You’re Prompting Opus 5.5 Wrong (Anthropic’s Guide to Mastering Opus 5.5) · Channel: Better Stack · 06:40 · Watch on YouTube

Topics: AI agents, Claude Code, Prompt and context engineering, Software engineering with AI, AI safety

Summary

The video summarizes Anthropic’s guidance for prompting Opus 5.5, emphasizing complete task descriptions, clear success criteria, and fewer vague instructions such as “think carefully.” For long-running work, it recommends adding follow-ups without stopping the run, defining when Claude should pause, and tracking complex tasks in files or across sub-agents. After a run, review Claude’s summary and have the code checked for actionable issues. The video also covers safety flags that may trigger a switch to an older model, and suggests asking Claude directly for a quick answer when speed matters.

Key points

Give Opus 5.5 the whole task in one message, define what completion means, and let it work with minimal oversight.
Remove generic prompt phrases such as “think carefully” and “think step by step”; use specific requirements and finish lines instead.
For design tasks, name specific styles or elements to avoid rather than relying on vague requests like “avoid generic look.”
In Claude Code, send follow-ups while a run is in progress instead of stopping and restarting it.
Add a Claude MD rule explaining when Claude should keep going and when it should stop and ask for help.
For large tasks, use sub-agents and ask Claude to verify their evidence; track progress in a file such as tasks.md.
Read the “needs from you” part of the final summary first, and request a code review that lists actionable merge-blocking problems.
Safety flags may switch Claude to an older model; clarify that vulnerability work concerns your own code, and consider starting a new thread after a flag.
For a quick response, explicitly ask Claude to “answer quickly” or “answer directly”; fast mode uses the same model but costs more per token.

Chapters

Start	Chapter	Summary
00:00	Prompting Opus 5.5 before a run	The video introduces Anthropic’s guide and recommends giving the full task, defining success, and removing unnecessary reasoning instructions.
02:06	Steering long-running tasks	The video explains how to add follow-ups without interrupting a run, set stopping rules, delegate work to sub-agents, and track progress in a file.
03:37	What to do when a run finishes	The video recommends checking what Claude needs from you, then reviewing the code for concrete, actionable problems.
04:38	Safety flags and model switching	The video describes how safety flags can move a conversation to an older model and offers ways to revise the prompt or start a new thread.
06:10	Getting a quick answer	The video notes that fast mode costs more and suggests asking Claude directly to answer quickly or directly.

Quotes

Opus 5.5 can think for longer on its own, and it always thinks first — 00:00

make sure that you say what done actually is. — 01:03

keep going unless you need me or unless it’s something destructive. — 02:37

A file survives that — 03:37

Literally say something like answer quickly or answer directly — 06:10

Concepts and entities

Opus 5.5, Anthropic, Claude Code, CLAUDE.md, subagent, context window, fast mode, Opus 5, OpenAI, Astra

Full transcript (original language)

00:00 If you still include things in your prompts like think carefully or make no mistakes, it might be time to rethink how you prompt. Opus 5.5 can think for longer on its own, and it always thinks first, so some of your old habits have got to go. Luckily, Anthropic just published a guide on getting the most out of Opus 5.5, so I pulled in the best tips, including the one Claude MD rule that will stop it pausing on a long run and asking if you want to continue, and also why you might find yourself using an older model halfway through your chat.

00:32 I’ve ordered these like we’re going through a task, so we’ll start by tackling what to say before we even hit enter, how to steer it while it’s running, and then what to do when it’s done. So, first up, before you hit enter, how to ask. Start by giving it the whole task in one message and then saying what done looks like, and then just letting it get on with the work. This might be an adjustment to some people used to older models that needed more hand-holding on a longer task, so you do everything in stages, but now they’ve tested Opus 5.5 on long-running coding tasks, and it barely needs any oversight. But, you should always make

01:03 sure that you say what done actually is. In Anthropic’s example, which is a payment migration, done means that every endpoint uses the new client, the old one has been deleted, and all of the tests pass. You could also add an extra line where you say only stop if a test fails for a reason that you can’t explain, and that way it should just get on with it and try to solve its own problems. While we’re here working on the prompt, there’s something else that you should delete from your prompt and all of your skills. Delete anything that says think carefully or think step by step. It’s no longer needed as Opus 5.5 always thinks before it replies, and it

01:35 decides how much. And Anthropic have actually tested this. Removing those lines make Claude start replying sooner with no clear drop in quality. You’ll find that that’s the pattern with this model. Vague instructions like think carefully don’t really do much, but specific ones where you give it a finish line are really beneficial. That shows up in design as well. If you give it no design direction, it will fall back to a few specific default styles and if you say avoid generic look, it’s mostly just going to swap one template out for another. What actually works when it comes to design is giving it a specific

02:06 list of styles that you don’t want. One that’s quite good at the moment is banning numbered sections, monospace labels, and pill-shaped buttons. AI absolutely loves monospace at the moment. You can go ahead and hit enter on your prompts now and now that Claude’s running, this is one that I’m quite guilty of. Stopping Claude to add something that I forgot. Runs go on for longer now, so restart actually costs more. So instead, in Claude code, just type your follow-up and it will just work. It will read it as soon as the current step finishes without stopping the current run. Talking of stopping,

02:37 you might also have the other common problem, which is where Claude stops when you didn’t want it to and while Opus 5.5 does give you small updates as it works, Anthropic do find that it occasionally stops to report something to you instead of carrying on with the task. So to fix this, you can add a rule to your Claude MD outlining when it should stop and when to keep going. You can add something as simple as keep going unless you need me or unless it’s something destructive. That should give it fewer full stops, but also ensure that it does still stop when you want it to. Now if the run you’re working on is

03:07 quite big, there are two things you might want to keep track of. The first one is if you’re doing something like an audit or a migration across a large code base, you should ask it to split this work across sub-agents and check each result. I find that this keeps the context smaller for each agent, which usually makes them a bit smarter, but it also gives you a multi-step review because the guide prompt tells it to check each sub-agent’s evidence before accepting it. The second thing that’s useful to do in a long-running task is ask Claude to keep track of its tasks in a file like tasks.md. A long run tends

03:37 to fill up the context window, so Claude code summarizes its older turns and that can mean that you lose some of the original tasks or some of that detail. A file survives that, so you can open it and see what’s been done, what’s left, and Claude can also see what he was working on, too. So once a run finishes, then what? Well, you’ll typically find that when Claude finishes a run, its final summary says what it did, what it found, and what it needs from you. So, when a long run ends, read the needs from you part first. Honestly, I sometimes find myself just asking a quick follow-up, asking what steps I

04:07 need to take before we can move on, and that’s what skills like ADHD have been made for, putting what you need to do up front. You could add this to your Claude MD with something like end every run with three headings: blocked on me, changed, and found. But, that summary will only tell you what Claude thinks it did. A code review, on the other hand, will tell you whether it’s actually right, and Opus 5.5 is actually pretty good at them. One early tester said that Opus 5.5, at its lowest effort level, caught more bugs than Opus 5 at high with fewer false alarms. They say that you should have a review a diff before a

04:38 person does, and only list the problems that you block a merge for with the file, line, why it’s wrong, and how to show that it fails. Honestly, I only partially agree with this one. I prefer it when my implementer and my reviewer are actually different models, and since I’ve got an OpenAI subscription, I probably get Astra to do the review and pass its feedback notes back to Opus. I just find that you get more unique results when you do it that way. Speaking of other models, then, sometimes you’ll actually find that Claude has moved you on its own to an older model, and that happens when your message gets flagged. Opus 5.5 is the

05:09 first Opus model with Fable-level bio and cyber safeguards, so it’s a lot more cautious than Opus 5. You are still allowed to find vulnerabilities in your own source code, but those safeguards can flag legitimate work, and Anthropic say they’ve been tuning this, but I must admit, even I’ve hit those safeguards when doing legitimate work in my own code base. When it does happen, there are a few things that you can do. In Claude code, you can press escape twice to edit your last message. Maybe try and modify your prompt so it sounds less suspicious, and make sure that it knows you’re only trying to find vulnerabilities in your own code base.

05:40 Something that Claude is actually quite sensitive about is anything in your prompts about showing Claude’s internal reasoning, because that’s actually one of the flag categories, so that could be what’s tripping it. You’ll also want to decide whether it should switch models automatically for you or ask you first when this happens. You can find this in the settings of Claude Code, and I personally prefer they ask me first, just in case there’s a way that I can change my prompt, so it doesn’t get flagged, and I can stay on Opus 5.5. Another thing worth keeping in mind is that if you stay in the same thread and you switch the model back later to Opus 5.5, you might end up getting flagged

06:10 again, because that earlier message is still in the context. So, it’s probably best to just start a new thread when this happens. So far then, we’ve covered everything that happens when you’re doing a long-running task, but what if you just want a quick answer? Claude does have a fast mode that uses the same model, but you need extra usage turned on, and it costs more per token. So, personally, I steer clear of that one. The one tip that I would recommend though is that if you want something answered quickly, just say that to Claude. Literally say something like answer quickly or answer directly, and you’ll be surprised how much this can help sometimes. There we go. Those are

06:40 my favorite bits from this guide, and most of it boils down to just being direct with Claude now. There’s a full checklist at the end of this post, so I’ll leave it linked in the description down below. Which of these tips did you find most helpful? Let me know in the comments. While you’re there, subscribe, and as always, see you in the next one.