—
“Help me with this” leaves a lot for a model to decide. “Follow these forty rules” can create a different problem: several rules may disagree, and the actual job gets buried underneath them. Claude Opus 5.5 prompting works best as a clear brief that makes the desired result easy to judge.
That doesn’t require an elaborate persona. Before asking the model to act as a world-renowned anything, explain what you need to receive, what material it should use and which decisions still belong to you. A short request can contain all of that.
Define the job before assigning a persona
Suppose you want Claude Opus 5.5 to help prepare for a community workshop. The useful starting point is the unfinished work: perhaps you have an agenda, a room booking and a list of questions from attendees. The job could be to identify missing decisions. It could be to draft an invitation. Those are separate requests.
Here is an illustrative prompt template for the first job:
Read the agenda and attendee questions below. Identify decisions the organisers still need to make before the workshop. For each decision, explain what remains unresolved and which part of the material raised it. Do not draft invitations or change the schedule. If the documents disagree, show the disagreement. Return a short working note for the planning meeting.
This gives the model something to do and a stopping point. It also makes a useful answer recognisable. A list of unresolved decisions can be compared with the supplied material; a polished essay about successful workshops cannot satisfy the same brief.
The task boundaries matter as much as the requested output. If the room booking is fixed, say so. If the agenda is provisional, say that too. Otherwise the model has to infer whether it is allowed to solve a timing problem by moving the meeting, removing a session or suggesting another venue.
Put the source material after the request under clear labels. “Current agenda” and “Questions received” are more useful than two unlabeled blocks of pasted text. Anthropic’s Opus 5.5 prompting guidance also calls attention to separating instructions from material pasted into a conversation. A sentence inside a document should be treated as document content, rather than silently becoming a new instruction to the assistant.
That distinction becomes practical when an email thread contains someone else’s requests. You may want the model to summarise those requests, without carrying them out.
Claude Opus 5.5 prompting needs room for useful decisions
A good brief can be precise about the result while leaving the route open. You don’t need to prescribe the order in which the model reads every paragraph. You do need to explain which facts are binding and what would make the answer unsuitable.
For the workshop example, success criteria might be that every proposed decision points to a supplied passage, that already settled matters stay settled, and that the note fits on one page. These criteria affect the usefulness of the result. Requiring exactly seven headings would mostly affect its appearance.
There is a difference between a preference and a requirement. “Use plain English” is a preference about presentation. “Do not change the confirmed date” protects a decision. When both are buried in a long list, the model receives little help identifying what matters most. Place the fixed facts close to the task.
Examples can help when a phrase is ambiguous. Instead of asking for a “strategic” answer, show the kind of decision you mean: whether to reserve time for questions, for instance, rather than whether to buy a different brand of marker. Keep that example brief. A lengthy sample can accidentally become a second assignment.
Avoid adding a rule merely because it sounds sophisticated. Instructions to be exhaustive, concise, creative, conservative and fast don’t explain which trade-off to make when those goals conflict. Decide what the task needs. A note for tomorrow’s meeting might need the three unresolved matters that block preparation, with the rest left for later.
The same brief can be tried with GPT-6 Astra when comparing how different models handle a task. Keep the source packet and acceptance criteria unchanged. Read whether each answer found the unresolved decisions; do not award extra credit for a confident tone or a longer explanation.
Change one instruction, then read the result
If the first answer misses the point, inspect the miss before rewriting the whole prompt. Did it misunderstand the job? Did it use the wrong source? Did it find the right issue but describe it badly? Each failure calls for a different correction.
A model that invents a venue needs a stronger boundary around the supplied facts. A model that produces an invitation needs the deliverable clarified. A model that identifies useful questions in cumbersome language needs an editing request. Adding more personality instructions won’t address all three.
Save the original request beside the revised version. This makes it possible to see whether the change actually helped, rather than remembering only that the second answer felt better. For repeated work, retain a small set of examples with known expectations and revisit them when changing the brief.
Anthropic documents thinking as always enabled for Opus 5.5, with effort controls available in supported integrations. That is a separate setting from a well-written request. A more expensive or slower run cannot supply a missing room booking, and it cannot know which decision the organisers have already made unless that information is available.
For repeated Claude Opus 5.5 prompting, keep the brief that produced a useful result and a note of why it worked. Add a rule when a real failure shows what is missing. Before the next workshop, update the dates and fixed decisions; the saved prompt cannot know that those have changed.
—
