Claude Opus 5.5 prompts: what to remove, what to add and examples

With Claude Opus 5.5 the prompt changes in a precise direction: it takes away more than you add. The lines that for two years have served to reason the models — "think carefully", "step by step" — with this model only slow down, because Opus 5.5 always thinks before answering and decides for itself how much.

What needs to be added is something else: the finish line. What does it mean that the task is finished, and when the model has to stop to ask you something. It is the biggest change, and it applies both in the app and in Claude Code.

This guide is based on the official guide published by Anthropic on launch day, with its examples reproduced faithfully and translated. Data verified on 23 September 2026.

What to Remove from Prompts

If you have prompts written for Opus 5, Sonnet or models from other providers, this is cleaning to do first.

The point about reasoning deserves an extra line. With Opus 5.5 the reasoning is Adaptive: the model chooses how much to think based on the task, inside a level that you can set. Asking him to "think more" in the prompt text does not raise the level: it confuses him. The level is chosen elsewhere, as explained in the reasoning levels of Opus 5.5.

What to add: the finish line

For multi-step tasks the official guide is clear: give the whole task in a message, and name the finish line. The text example, translated:

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

Three elements, always the same:

1. The Whole Task, not the first step. The model plans better if it sees where it has to go.
2. The definition of "finished", verifiable: tests pass, every record has migrated, the document has no contradictions.
3. The Stop Rule: in which cases he must stop to ask you, and in which cases he must not.

It also applies outside the code. For a draft contract: "Finished means: all the clauses of the model are present, the names of the parties are consistent on each page, no date is in the past. Stop only if a fact is missing that you can't infer."

Correcting in the race

On a long job there is no need to interrupt and start again: you can send a message while the model is working. The example of the guide: "Also keep old endpoint names as aliases." The model integrates it without starting from scratch, and you save the cost of restarting.

It works well for the precisions that come to your mind along the way; not to change your goal. If the goal changes, the new message is a new task.

Prompt for short answers

If you want a dry answer — a yes or no, a line, a number — write "Reply directly". The model reduces internal reasoning and the answer comes first. It is the only case where it makes sense to talk about reasoning in the prompt: to ask for less, not more.

Prompt for design: exclude, not describe

A specific but instructive case. To get a page that doesn't seem generated, "avoids a generic appearance" doesn't work. It works the list of habits to be excluded. The example of the guide, translated:

"Build a personal site with placeholder content. Do not use a cream or off-white background, words in italics such as accent in titles, section labels numbered 01/02/03, monospace labels, or pill-shaped buttons."

The principle applies everywhere: specific exclusions beat generic instructions. "Nothing 'we apologize for the inconvenience'" works; "be friendly but not formal" does not.

Ask for verification, not reassurance

For research and analysis, a line that changes the result: "Mark everything you couldn't confirm, and tell me where you searched." Get an answer with the declared weak points instead of a confident text that you then have to check again. It's the simplest defense against the invented answers.

For long documents the guide proposes: "Check that this document does not contradict itself: numbers, dates and names. Quote every problem and tell me where it is." How to use it on quotes and contracts is in have Opus 5.5 check a document.

Eight prompts ready

The system prompt in automatic systems

In chats the prompt writes it every time; in automatic systems there is a system prompt which is sent back identically to each call. With Opus 5.5 it is worth rewriting for three reasons.

The first is the cost: every pointless line you pay for it at every run, and with the cache at $0.20 per million tokens the fixed part of the prompt only costs little if it is really fixed. The second is latency: lines on reasoning lengthen the time before the first word, as explained in time to first token. The third is quality: a system prompt describing the task with the arrival line produces more stable output than one describing the desired behavior with adjectives.

A structure that works, in this order: who is the user and what the company does in two lines; the task with the definition of "finished"; the exact format of the output; what never to do; what to do when a data is missing. Nothing "you're an expert and precise assistant": nothing changes, and it occupies tokens.

Practical examples

Law Firm, 6 people, Verona. The prompt for the first reading of the contracts contained three lines of "analyze with the utmost care, reason clause by clause". Tolte, the answer comes first and doesn't change anything in quality. Added the finish line — "finished means: every clause in our model is present or reported as missing" — the answer became a verifiable list instead of a comment.

Communication agency, 12 people, Milan. For landing pages the brief said "modern, clean, not generic" and always came out the same site. Replaced with a list of seven things not to do, taken from jobs discarded in previous months. The result is not "better" in the abstract: it is different every time, which was the problem.

Background after restart

Persistent instructions are not enough for data that changes during work. SessionStart and compaction allow you to reason on which dynamic context to add and how much. If the problem is knowing when to intervene, the local Claude Code notifications They separate expected input and end of response, without turning each event into an external message.

Mistakes to Avoid

• Copying the "secret techniques" from the forums. Almost all of them were born on models that didn't reason alone.
• Giving the first step instead of the whole task. The model plans worse and asks you for confirmation all the time.
• Defining "finished" in an unverifiable way. "When it's done right" is not a finish line.
• Asking to show the internal reasoning. It is reported, and the response switches to an earlier model.
• Describing the style with adjectives. Concrete exclusions work, "elegant" doesn't.

How to apply it in the company

If your company shares prompts — in automated systems or workplace chats — this is the review to carry out once:

1. Search and Remove each line on the reasoning: "think", "reason", "step by step", "carefully".
2. Add to each task prompt the line "finished means:" with verifiable criteria.
3. Add Stop Rule where the model acts on data or systems.
4. Evidence on the same cases as before and compare: if it gets worse, the problem is almost always a misspelled finish line.

For prompts that must also work on other models, see prompts that work on multiple models; for general collection, prompt for Claude.

Conclusion

The prompt for Opus 5.5 is shorter than for previous models and more precise on one thing: where it has to go. Remove the instructions on reasoning, write down what it means to be finished, say when to stop. The rest —examples, format, exclusions.is as good as ever.

Do you want to understand what processes in your company can be automated with AI? Giallo Studio can help you turn the problem into a real workflow.