The Ideal Prompt Structure for Claude Opus 4.7
Opus 4.7 does exactly what you ask, not what it guesses you meant. That single shift rewards prompts that are explicit, structured, and clear about what a good answer looks like. Here is a reusable structure, a copy-paste template, and the principles behind both.
Why Opus 4.7 changed how you prompt
The model is more capable, but the practical change that matters most for everyday prompting is how literally it reads your instructions.
Earlier models were generous interpreters. If your instruction was vague, they filled in the gaps with a reasonable guess. Opus 4.7 leans the other way: it takes your words at face value.
If you write "respond in JSON," it returns JSON and nothing else, where an older model might have added a friendly sentence first. If you write "write exactly three functions," it writes three, even when a fourth would be cleaner. This is a feature, not a quirk. It means a precise prompt now produces a predictable result. It also means a sloppy prompt produces a literal, sometimes surprising one, and burns reasoning effort getting there.
Everything in this guide follows from that. Structure your prompt so there is nothing left to guess, state what a finished answer looks like, and Opus 4.7 will reward you with consistency.
The one-line takeaway
Write the prompt you would hand to a sharp new colleague who will do precisely what the words say and nothing more.
Precision beats verbosity. Add detail because it removes ambiguity, not to pad the request.
The ideal prompt structure
Strong prompts tend to share the same skeleton. Each layer answers a question the model would otherwise have to guess. You will not need every layer every time, but this is the order that reads cleanly and scales from a one-line ask to a long, multi-step task.
Tell the model who it is and the situation it is operating in. A clear role sharpens vocabulary, depth, and judgment. Best placed in the system prompt when your tool supports one.
State the single objective in one or two plain sentences. This is the load-bearing line. Say exactly what you want produced, not a general topic to explore.
Explain the audience, why the task matters, and any constraints or definitions. Telling the model why you want something helps it make better calls on the parts you did not spell out.
Paste the source documents, data, or notes the model should work from. For long inputs, keep this block near the top of the prompt and the task near the bottom.
Give the steps or rules as a short numbered list. Phrase them as what to do. Cover the edge cases you care about, such as what to do when information is missing.
Show one to three worked examples of input mapping to ideal output. A single good example often does more than a paragraph of description, especially for formatting and tone.
Describe the exact shape of the answer, then state how you will know it is correct and complete. Success criteria are the part most prompts skip and the part that fixes the most disappointing results.
For anything involving reasoning, ask the model to think through the problem before it answers. On 4.7 the thinking is hidden by default, so request a visible reasoning section if you want to see the work.
The ordering rule for long inputs
When you include a large document or dataset, put it near the top of the prompt and put the actual question at the very bottom, right before the model responds.
A fact buried in the middle of a long prompt is easy to miss. If a detail is essential, restate it next to the task so it sits where the model is paying the most attention.
The master template
Drop your own content into the placeholders. Delete any layer you do not need. The XML-style tags are not magic words; they simply give each section a clear boundary so the model never confuses your instructions with your data.
<role>
You are a [role] helping with [domain or situation].
</role>
<task>
[State the single objective in one or two sentences. Be literal:]
[say exactly what you want produced.]
</task>
<context>
Audience: [who this is for]
Why it matters: [the goal behind the task]
Constraints: [length, tone, must-haves, must-avoids]
Definitions: [any term the model should read a specific way]
</context>
<reference>
[Paste source documents, data, or notes here.]
[For long inputs, keep this block near the top.]
</reference>
<instructions>
1. [First explicit step]
2. [Second explicit step]
3. [Say what to do when something is missing, rather than guessing]
</instructions>
<examples>
<example>
Input: [a representative input]
Output: [the ideal output for that input]
</example>
</examples>
<output_format>
[Describe the exact structure: sections, table, JSON schema, length.]
Success looks like: [the criteria that make the answer correct and complete.]
</output_format>
Think through the problem inside <thinking> tags before you write the final answer.Nine principles that make prompts work
The structure above is built on a handful of ideas. Understand these and you can adapt any prompt on the fly, not just fill in a template.
Be explicit, not suggestive
Opus 4.7 follows the literal instruction. Write the outcome you want directly instead of hinting at it and hoping the model reads between the lines.
State the success criteria
Tell the model how to recognize a finished, correct answer. This is the single highest-leverage line you can add and the one most prompts leave out.
Separate sections with tags
Wrap instructions, context, and data in distinct XML-style tags. Clear boundaries stop the model from mistaking your reference material for a command.
Show, do not only tell
One worked example of input to output communicates format and tone faster than any description. Add an example whenever the shape of the answer matters.
Give it room to think
For reasoning tasks, ask the model to work through the problem before answering. On 4.7 that reasoning is hidden unless you ask to see it, so request it when you need the workings.
Say what to do
Frame rules as positive instructions. "Use plain language" lands better than "do not be too technical," because it gives the model a target rather than a thing to avoid.
Pin load-bearing facts near the task
In a long prompt, restate any essential detail right next to the question. Facts stranded in the middle of a large block are the easiest for the model to overlook.
Match style to the output
Write the prompt in the register you want back. A crisp, well-formatted request tends to produce a crisp, well-formatted answer. The model takes cues from your example.
Invest in tool definitions
If the model can call tools, the tool descriptions are part of the prompt. Clear names, inputs, and one-line purposes do more for reliable tool use than anything in the user message.
Before and after
The same goal, prompted two ways. The vague version leaves the model to invent the format, the scope, and what to do with gaps. The structured version leaves nothing to chance.
Summarize these meeting
notes and tell me what
to do next.The model has to guess the format, decide what counts as an action, and may invent owners or dates to fill the gaps.
<task>
Turn the notes below into
a list of action items.
</task>
<reference>
[meeting notes]
</reference>
<instructions>
1. Capture commitments only,
not discussion.
2. Note the owner and due date
if they are stated.
3. If either is missing, write
"unassigned" rather than guess.
</instructions>
<output_format>
A table: Action, Owner, Due date.
Success: every commitment appears
once, with no invented details.
</output_format>The format is fixed, the scope is bounded, and the missing-data rule prevents the model from filling gaps with fiction.
What changed in 4.7, at a glance
If you are carrying over prompts that were tuned for an earlier model, these are the shifts worth re-checking. Opus 4.7 became generally available in April 2026.
| Change | What it means for your prompts |
|---|---|
| More literal instructions | Say exactly what you want. Loose phrasing that earlier models smoothed over is now taken at face value, so tighten anything ambiguous. |
| Thinking hidden by default | The model still reasons internally, but that reasoning is not shown unless you opt in. Ask for a visible reasoning section when you need to see the workings. |
| Fewer dropped subtasks | Long, multi-step requests hold together far better than before. You can hand it longer task lists and trust more of them to be completed. |
| High-resolution vision | It reads sharper images than earlier models, so detailed screenshots, charts, and scans are more reliable inputs. |
| New tokenizer | The same text can use noticeably more tokens than before. If you work near a context limit, leave more headroom than you used to. |
Pre-send checklist
A thirty-second pass that catches most of what makes a prompt underperform.
The task is one clear sentence. A stranger could read it and know exactly what to produce.
Success is defined. You have written what a correct, complete answer looks like.
Data and instructions are separated. Reference material sits in its own tagged block.
Rules are phrased as what to do. No instruction relies only on telling the model what to avoid.
The output format is explicit. Structure, length, and shape are spelled out, not implied.
Edge cases are covered. You have said what to do when information is missing or ambiguous.
For long inputs, the question sits at the end. Essential facts are restated next to the task.
Further reading
The official documentation from Anthropic, which informed this guide.
Prompting best practices →
The full guide to clarity, examples, XML structure, thinking, and agentic systems.
What is new in Opus 4.7 →
The model-level changes behind the prompting shifts described above.