How to Write Better Claude Prompts

Claude is trained with XML-style tags as structural delimiters and responds to them reliably. When you wrap distinct sections — instructions, context, examples, the user's query — in named tags, Claude treats each section according to its label rather than guessing where one idea ends and another begins. This is the single cheapest improvement most prompts can make.

Without XML tags, a prompt that mixes instructions with context frequently causes Claude to apply instructions selectively or conflate the user's query with the reference material. With tags, each element is unambiguous. Anthropic's guide on using XML tags covers the mechanics in detail — the short version is: tag names can be anything meaningful, and nesting is supported.

Tags are especially critical when your prompt contains all three of: long background context, multi-step instructions, and a variable user input. Without delimiters, Claude's attention is spread unevenly. With them, it processes each region in context. See our dedicated post on how to use XML tags in prompts for extended patterns.

Copy-paste example — without XML tags (weak): ``` You are a legal assistant. Here are the contract terms: Payment is due in 30 days. Late fees are 1.5% per month. Jurisdiction is California. The user asks: Can we extend the payment terms to 45 days? Answer professionally. ``` With XML tags (strong): ```xml <system> You are a senior contract attorney specializing in commercial agreements. </system> <contract_excerpt> Payment is due in 30 days. Late fees are 1.5% per month. Jurisdiction is California. </contract_excerpt> <user_question> Can we extend the payment terms to 45 days without triggering the late fee clause? </user_question> Review the contract excerpt and answer the user's question directly. Cite the relevant clause. ``` The tagged version consistently produces a clause-specific answer; the untagged version frequently returns a generic explanation of payment terms.

Claude treats the system prompt and the human/user turn as fundamentally different inputs. The system prompt sets persistent context — your persona definition, output rules, constraints, formatting requirements, and anything that should apply across the entire conversation. The user prompt is the dynamic, per-request input. Mixing them produces prompts that reset on every turn or fail to maintain consistent behavior.

The practical rule: anything you would write in a style guide or a job description goes in the system prompt. Anything that varies call-to-call goes in the user turn. If you are building a product on Claude, the system prompt is your primary engineering surface. Anthropic's system prompt guide is required reading for anyone deploying Claude-backed applications.

See also: system prompt vs. user prompt explained and how to write a system prompt for full treatment of each layer.

Copy-paste example — system prompt for a B2B SaaS support assistant: ``` System prompt: You are a support specialist for DataFlow Pro, a B2B analytics platform. You speak in plain, direct language — no jargon, no hedging phrases like "certainly" or "great question." Always: 1. Confirm what the user is asking before answering (one sentence). 2. Give the answer in numbered steps when the resolution requires more than one action. 3. If the issue requires escalation, say: "This needs a human — I'm opening a ticket now." and stop. Never discuss competitor products. Never speculate about pricing outside the published tiers. User turn (runtime, per-message): [user's support message goes here] ``` The system prompt does the heavy lifting once. Every user-turn prompt stays clean and focused on the actual request.

Telling Claude what format you want is less reliable than showing it two or three completed examples. Multishot prompting (also called few-shot) is particularly powerful for output formatting, tone calibration, and task-specific vocabulary. Claude generalizes from examples faster than it follows abstract instructions, especially when the output pattern is non-standard.

For high-volume tasks on Claude Haiku 4.5 — classification, data extraction, short-form generation — multishot examples are the primary quality lever because you cannot use extended thinking at that tier. A well-crafted three-example prompt on Haiku 4.5 often matches the zero-shot quality of Sonnet 4.6 on the same task, at a fraction of the cost. Anthropic's multishot prompting page shows the canonical pattern.

The examples should be representative of the real distribution of inputs — including edge cases — not just the easy ideal case. If your task occasionally gets messy inputs (typos, incomplete data, off-topic requests), include one example that shows how Claude should handle it.

Copy-paste example — product category classifier: ```xml <examples> <example> <input>Wireless noise-cancelling headphones, 30-hour battery</input> <output>{"category": "Electronics", "subcategory": "Audio", "confidence": "high"}</output> </example> <example> <input>Organic cold-pressed extra virgin olive oil, 500ml</input> <output>{"category": "Grocery", "subcategory": "Oils & Condiments", "confidence": "high"}</output> </example> <example> <input>Replacement battery for model XJ-200 (unknown brand)</input> <output>{"category": "Electronics", "subcategory": "Accessories", "confidence": "medium"}</output> </example> </examples> Classify the following product using the same JSON schema: <input>Adjustable standing desk converter, 32 inch width</input> ``` With this pattern, Claude Haiku 4.5 returns correctly-formatted JSON on >95% of inputs without any additional JSON mode configuration.

In the Anthropic API, you can pass a partial assistant message as the last entry in the messages array. Claude treats this as the beginning of its own response and continues from where you left off. This is one of the most reliable ways to enforce output format: if you prefill with `{`, Claude returns a JSON object. If you prefill with `## Summary`, Claude starts with a markdown heading. If you prefill with `1.`, Claude returns a numbered list.

Prefilling eliminates the common problem of preamble — the sentences Claude sometimes emits before the actual content ("Sure, here is the JSON you requested:"). It also prevents Claude from wrapping JSON in code fences when you need raw JSON, and forces it into whatever structural starting point your downstream parser expects. Anthropic documents this technique under prefill Claude's response.

Note: prefilling is available in the raw API via the assistant message position. In Claude.ai's UI you cannot prefill directly, but you can end your user-turn message with a transitional phrase that achieves a similar effect (e.g., "Return ONLY a JSON object, starting immediately with `{`.").

API example — force raw JSON with no preamble: ```python import anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-sonnet-4-6", max_tokens=1024, system="You are a data extraction assistant. Extract structured data from text.", messages=[ { "role": "user", "content": "Extract the name, email, and company from: 'Hi, I'm Sarah Chen (sarah@acme.io) from Acme Corp.'" }, { "role": "assistant", "content": "{" # <-- prefill starts the JSON object } ] ) # Response will be the continuation of the JSON object, no preamble ``` This pattern is especially valuable in agentic pipelines where Claude's output is parsed programmatically.

For tasks that require multi-step reasoning — math, logic puzzles, code debugging, complex analysis, strategic planning — explicitly asking Claude to reason before answering improves accuracy significantly. The basic version is a simple instruction: "Think step by step before giving your final answer." The advanced version uses Claude Opus 4.8's extended thinking feature, which gives the model a dedicated reasoning scratchpad before it produces visible output.

Standard chain-of-thought is model-agnostic and works on Sonnet 4.6 and Haiku 4.5. Extended thinking (Claude's version of explicit reasoning traces) is most powerful on Opus 4.8 and is activated via the API's `thinking` parameter. Anthropic's extended thinking documentation explains the API configuration. See also our chain-of-thought prompting guide for a full treatment of both standard and extended approaches.

The practical difference between asking for CoT and not asking for it is largest on problems where the answer depends on correctly sequencing multiple intermediate inferences. For simple factual retrieval or single-step formatting tasks, CoT adds tokens without adding value — so gate its use on task complexity.

Copy-paste example — standard CoT instruction: ```xml <task> A SaaS company has 1,200 monthly active users. Their churn rate is 3.5% per month. They acquire 55 new users per month. What is their approximate user count in 6 months? </task> <instructions> Work through the month-by-month math in a <scratchpad> block first. Then provide a final <answer> with the number and a one-sentence interpretation for a non-technical executive. </instructions> ``` For extended thinking on Opus 4.8 (API): ```python response = client.messages.create( model="claude-opus-4-8", max_tokens=16000, thinking={ "type": "enabled", "budget_tokens": 10000 }, messages=[{"role": "user", "content": your_complex_problem}] ) ``` Extended thinking consistently outperforms standard prompting on competitive math, multi-constraint optimization, and code architecture tasks.

The single most common source of off-target Claude output is an implicit expectation that Claude will infer the right format, length, scope, or persona from context. Claude will infer something — but it will infer what the average person asking a similar question would want, not what you specifically need. Explicit instructions override inference.

Explicit means: state the output format ("return a JSON array"), the length ("under 200 words"), the scope ("cover only the product's pricing section, not the feature set"), the audience ("written for a CFO who has no engineering background"), and any hard constraints ("do not use the phrase 'best practices'"). Every implicit expectation you leave unstated is a variable Claude resolves on its own.

Anthropic's being clear and direct page has a useful framing: treat Claude like a highly capable new colleague who has no context about your preferences, your audience, or your internal standards. That colleague needs complete, explicit direction — not hints.

Before (implicit, frequently wrong): ``` Summarize this article for our newsletter. ``` After (explicit, reliably correct): ``` Summarize the article below for our weekly B2B marketing newsletter. Requirements: - Length: 3 sentences maximum - Audience: marketing directors at mid-market SaaS companies - Tone: factual and direct, no hype language - End with one sentence on why this matters for pipeline teams - Do not use the word "leverage" or the phrase "game-changer" <article> [article text here] </article> ``` The explicit version returns a newsletter-ready paragraph on the first attempt; the implicit version requires 2-3 revision cycles to get length and tone right.

Giving Claude a specific role in the system prompt shifts its default vocabulary, reference frame, and output style. A prompt that says "You are a senior backend engineer at a fintech company" produces code with different conventions and documentation assumptions than one that says "You are a Python tutor for beginners." The role shapes what Claude treats as assumed knowledge and what it explains.

Role assignment is most effective when the role carries an implicit set of standards that aligns with what you want. "You are a Michelin-star restaurant critic" brings a specific lens to food writing. "You are a trial attorney preparing opening arguments" brings structured adversarial thinking to any argument task. "You are a skeptical venture capitalist reviewing a pitch" brings financial and market-risk thinking that a generic "assistant" role does not.

See our full guide on how to assign a role in a prompt for advanced patterns, including how to layer multiple roles and how to use role assignment alongside persona constraints. The key mistake to avoid: assigning roles that are too generic ("You are a helpful expert") — specific roles outperform vague ones consistently.

Copy-paste example — two roles, same underlying task, different outputs: ``` # Role A: generic System: You are a helpful writing assistant. User: Review this paragraph for clarity. # Role B: specific System: You are a developmental editor at a business book publisher whose clients include CEOs and investors. Your editing priorities, in order: (1) clarity of argument, (2) economy of words, (3) executive-appropriate vocabulary. User: Review this paragraph for clarity. ``` Role B produces prioritized, specific editorial feedback. Role A produces a generic "this is good, but maybe..." response. The underlying model capability is identical — the role determines how it's applied.

When your prompt includes long reference material — documents, codebases, research papers, conversation history — where you place that material relative to your instructions matters. Anthropic's own research and the long-context tips documentation are explicit on this: put long documents at the top of the prompt, before your instructions and question. This ordering improves Claude's ability to ground its response in the source material.

The intuition: Claude processes context in order. Instructions that come after a long document are more likely to be applied to the just-read content. Instructions that come before a long document are more likely to be interpreted as a general framing that may or may not survive 100k tokens of context. For retrieval-heavy tasks on Claude Opus 4.8's 200k-token context window, correct document placement can be the difference between a sourced, accurate response and a response that ignores half the input.

The structural pattern for long-context prompts: ```xml <!-- 1. Documents first (longest content) --> <document id="1"> [full text of document 1] </document> <document id="2"> [full text of document 2] </document> <!-- 2. Instructions after documents --> <instructions> Using only the documents above, answer the following question. Cite each claim with the document ID. </instructions> <!-- 3. The actual question last --> <question> What are the three most significant risks identified across both documents, and do they contradict each other? </question> ``` This ordering consistently produces responses that cite specific sections rather than paraphrasing from memory. For multi-document analysis on Opus 4.8, it reduces hallucination measurably.

Claude defaults to markdown formatting in most contexts — headers, bullet points, bold text, code fences. That default is right for many use cases and wrong for others. If you are parsing Claude's output programmatically, rendering it in a UI that doesn't interpret markdown, or feeding it into another model, raw-text or explicit-schema output is what you need. The fix is explicit format instructions, not hoping Claude infers the context.

For JSON output: either use the prefilling technique from section 4, or state explicitly: "Return ONLY valid JSON matching this schema: `{...}`. Do not include any text outside the JSON block." For plain prose: "Use plain text only. No markdown formatting, no bullet points, no headers." For structured reports: provide the exact skeleton and ask Claude to fill it in. Anthropic covers the formatting layer in controlling output format.

Format control also governs length. Vague length guidance ("be concise") is less reliable than precise guidance ("the entire response must be under 150 words"). For Claude Haiku 4.5 in high-volume classification tasks, tight output constraints also reduce token spend — a response that says `{"label": "positive"}` costs 5 output tokens; a response that says "Based on the sentiment expressed in the text, I would classify this as positive" costs 25. At scale, that gap is material. See our AI Prompt Cost Calculator to quantify it for your workload.

Copy-paste example — explicit format schema: ```xml <instructions> Analyze the customer feedback below and return your analysis in this exact structure: SENTIMENT: [positive | neutral | negative] MAIN_TOPIC: [one phrase, under 8 words] ACTION_REQUIRED: [yes | no] PRIORITY: [1-5, where 5 is most urgent] SUMMARY: [one sentence, under 20 words] Return ONLY this structure. No preamble, no explanation. </instructions> <feedback> [customer feedback text here] </feedback> ``` This schema-constrained format parses with a five-line regex and returns consistent results across thousands of Claude Haiku 4.5 calls.

Most high-performance Claude prompts combine several techniques rather than relying on any single one. Below is a template that layers the highest-impact elements: system prompt with role, XML-tagged context, multishot example, explicit instructions, and a prefilled response start. Use this as a starting skeleton and strip out layers you don't need for simpler tasks.

Full template for a research summarization assistant: ```xml <!-- SYSTEM PROMPT --> You are a research analyst specializing in competitive intelligence for B2B software companies. You write for an executive audience: precise, direct, no hedging language, no jargon. <!-- USER TURN --> <example> <source>Gartner Q1 2026 CRM Magic Quadrant, excerpt: Salesforce maintains Leaders position driven by AI feature velocity. HubSpot moved into Challengers on platform breadth concerns.</source> <summary>THEME: CRM market consolidation\nKEY MOVE: HubSpot loses Leaders position due to platform gaps\nIMPLICATION FOR US: Opportunity to position against HubSpot in enterprise segment</summary> </example> <source> [paste your source document here] </source> <instructions> Summarize the source above using the same three-field format shown in the example: THEME, KEY MOVE, IMPLICATION FOR US. Under 60 words total. Do not use the word "leverage". </instructions> ``` Prefill the assistant turn with `THEME:` to prevent preamble. The output will be clean, parseable, and consistently formatted across hundreds of calls.

For teams running this at scale on Claude Sonnet 4.6, the combination of tight output schema and XML-structured input typically cuts token usage 30-40% versus freeform prompts that produce verbose, markdown-heavy responses. Prompt caching on the stable portions (system prompt + example) reduces input cost further. If you want to estimate the combined savings for your specific call volume, the AI Prompt Cost Calculator handles multi-technique scenarios.

Not every technique maps to every model equally. Here is the practical routing guide for Claude Opus 4.8, Sonnet 4.6, and Haiku 4.5 based on the nine techniques above.

Claude Opus 4.8 — use when: extended thinking is required (sections 5), long-context structuring with 100k+ token documents (section 8), complex multi-constraint tasks where standard CoT on Sonnet 4.6 produces incorrect reasoning. Opus 4.8 also benefits most from explicit role assignment (section 7) because the depth of its domain knowledge means the right role unlocks qualitatively different output. Cost: premium — reserve for tasks where model quality is the bottleneck.

Claude Sonnet 4.6 — use for: the majority of production prompting tasks. All nine techniques apply. Sonnet 4.6 with a well-structured prompt (XML tags + explicit instructions + multishot examples) handles 90% of the tasks teams incorrectly escalate to Opus. Best balance of quality and cost for conversational applications, code generation, content creation, and analysis tasks under ~50k tokens.

Claude Haiku 4.5 — use when: high volume, latency-sensitive, or cost-constrained. Techniques that matter most at this tier: multishot examples (section 3) for quality, output format control (section 9) for downstream parsing, and explicit instructions (section 6) for consistency. Extended thinking is not available on Haiku 4.5. Prefilling (section 4) is especially valuable here — it forces correct output structure where the smaller model might otherwise drift. For a direct cost comparison across the Claude model family, see how much does Claude cost or run the numbers in the cost calculator.