How to prompt Claude Sonnet 4.5

Prompt Claude Sonnet 4.5 with the same XML-tagged sections as other Claude models, but at a middle length. Give the complete task in one message, keep the role to a sentence, and put hard limits in their own <constraints> block. Sonnet is Anthropic’s everyday model for coding and writing. It needs a fuller brief than Haiku and a tighter one than a long-running Opus agent.

The prompt structure

<instructions>
You are a technical writer for a developer-tools company.
</instructions>

<context>
We are deprecating the v1 REST API on 1 March. The v2 API uses
cursor pagination instead of page numbers. Readers are existing
API customers.
</context>

<task>
Write the migration announcement for our changelog.
</task>

<constraints>
Under 300 words. Name the deadline. No marketing adjectives.
</constraints>

<output_format>
Markdown: one H2 title, a short intro, then a "What changes" list.
</output_format>

The tags let Sonnet tell your instructions apart from your background material. That matters most when you paste in code, emails or documents. Include only the tags the task needs.

State the whole job at once

Sonnet does best when the entire task arrives in one message. Avoid “first give me an outline, wait for my approval, then write”. If the work really has steps, list them inside <task> and let the model run through them.

Say what’s out of scope as well as what’s in. If you want a three-bullet summary, note that a full memo isn’t wanted. Otherwise Sonnet may helpfully produce one.

Keep the role short

One sentence of role is enough to set tone and expertise. Several paragraphs of personality, collaboration rules and stop conditions add noise that competes with the actual task.

Write constraints as positive guidance

“Use neutral language that doesn’t assign blame” steers better than “don’t blame the vendor”, because it names the behaviour you want. Put numbers (word counts, languages, deadlines) in <constraints>. If the output shape depends on them, restate them in <output_format>.

Only include facts you actually know. If a detail is missing, write a placeholder such as [launch date TBD]. That’s better than letting a plausible invention slip into the brief.

One skeleton for every task type

The same tags work across different kinds of task. What changes is what you put in <output_format>:

• Code: ask for a diff when editing an existing file, rather than the whole file.
• Writing: name the genre, length and heading style.
• Analysis: say whether you want a decision with a recommendation, or a neutral summary.

Success criteria, not re-checks

For demanding work, add two or three checkable conditions in <success_criteria>, such as “the function keeps its signature” or “every figure comes from the pasted report”. Sonnet corrects itself reasonably well, so skip extra “double-check everything” instructions on top of that.

Why Sonnet prompts go wrong

• Vague tasks. “Make this better” gets generic advice back.
• No constraints. Tone and length drift.
• Several jobs mixed together without tags. Constraints get dropped.
• Too much context. Background buries the one line that says what to do.