How to prompt Claude Sonnet 4.5

Prompt Claude Sonnet 4.5 with the full task in one message, XML tags around each kind of content, and the long material above the question. Anthropic’s best practices say tags keep instructions, context, examples, and inputs from being read as one another, and that long documents belong at the top with the query underneath. A role can be one sentence in the system prompt. Sonnet is the everyday Claude model on this site: more context than a Haiku one-liner, and still a single brief rather than a multi-step agent script.

Give the complete job at once. If you need an outline and then the post, say both inside <task> and let the model do them. Do not ask it to wait. Put hard limits in <constraints>. If you include an example, wrap it so it cannot be mistaken for the assignment.

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.

When does Sonnet 4.5 answer a different job than the one you meant?

The task arrives in chapters. “Outline first, wait, then write” splits one job across turns. Anthropic’s clear-and-direct guidance, and this guide’s practice, is to put the whole assignment in the first message. Waiting instructions are extra tasks.

A long source sits under the question. Best practices say to put longform data at the top, above the query, the instructions, and the examples. A changelog paste that follows the question is in the wrong order for that pattern. Move the paste into <context> above <task>.

An example is loose in the prompt. Wrapped examples are how Claude is told “this is a sample, not the work.” A sample announcement left untagged is easy to continue instead of replace. If you do not need a sample, do not include one.

The role is a page long. A sentence of role is the documented minimum that changes tone. A biography of the company, the brand voice, and the legal policy in <instructions> competes with <task>. Move standing policy into <constraints> as checkable lines.

What does the same rough prompt look like for Claude Sonnet 4.5?

Same draft. Tags separate the facts from the job. Nothing new is invented.

write a blog post announcing our windows app is moving from 1000 one-off credits to a flat 13.99 a month plan, about 600 words, its for people already using it, dont be hypey

<instructions>
You write for people who already use the product.
</instructions>

<context>
Windows app.
Old price: 1,000 one-off credits.
New price: a flat 13.99 a month.
Readers already use the app.
</context>

<task>
Write the announcement post in this message. Do not wait for an outline approval.
</task>

<constraints>
About 600 words. No hype adjectives. Name both prices.
</constraints>

<output_format>
Prose announcement. No second version.
</output_format>