Prompt Engineering Tips for Claude Models
If you're searching for prompt engineering tips for Claude models, you're probably getting inconsistent outputs, overly verbose responses, or answers that ignore part of your instructions. Claude models respond well to structure, explicit reasoning instructions, and clear role definitions — but the techniques that work for other LLMs don't always transfer directly.
This article covers the specific patterns that reliably improve output quality with Claude: how to structure prompts, when to use XML tags, how to control verbosity, and how to debug prompts that aren't working.
Structure Your Prompt Like a Spec, Not a Conversation
Claude performs better when a prompt reads like a specification rather than a casual request. Vague prompts produce vague, hedged answers. Specific prompts produce specific, usable ones.
Instead of:
Write a product description for a water bottle.Try:
Write a 60-80 word product description for a stainless steel water bottle.
Audience: outdoor enthusiasts aged 25-40.
Tone: confident, no exclamation marks.
Include: insulation duration, capacity in ml, one sustainability detail.
Exclude: pricing, calls to action.The second version removes ambiguity about length, tone, audience, and scope. Claude doesn't have to guess what "good" looks like — you've defined it.
Use XML Tags to Separate Instructions From Content
Anthropic's own documentation recommends XML tags, and in practice they make a measurable difference, especially for longer prompts that mix instructions, reference material, and examples.
<instructions>
Summarize the following support ticket in 2 sentences.
Focus on the customer's core issue, not the greeting or sign-off.
</instructions>
<ticket>
Hi team, I've been trying to reset my password for three days and the
reset email never arrives. I checked spam. This is urgent, I have a
client call tomorrow and can't access my dashboard. Thanks, Maria
</ticket>Tags give Claude unambiguous boundaries. Without them, models sometimes blend instructions and content, especially when the content itself contains imperative language ("this is urgent"). With tags, Claude reliably treats <ticket> as data to process, not instructions to follow.
Use this pattern anywhere you're injecting user data, documents, or retrieved context into a prompt — it also reduces the risk of prompt injection from untrusted input.
Put Role and Constraints in the System Prompt
If you're calling the API directly rather than using the chat interface, the system prompt is the right place for persistent rules: tone, format, things to avoid, output structure. Keep the user turn focused on the actual task.
{
"model": "claude-sonnet-4-5",
"system": "You are a technical editor. Always respond in markdown. Never use emoji. Flag unsupported claims instead of removing them silently — note them in a final 'Flags' section.",
"messages": [
{ "role": "user", "content": "Edit this paragraph for clarity: ..." }
]
}This separation matters for maintainability too — if you're building an app on top of Claude, you can update the system prompt in one place without touching every call site. Teams running this through SubToAPI often keep a small library of system prompts per use case and swap them per request, since every call still goes through one application key regardless of which system prompt is active. See /docs/messages for the request shape.
Ask for Reasoning Before the Answer, Not After
For tasks involving analysis, comparison, or multi-step logic, explicitly ask Claude to reason first and conclude second. This is different from just asking for "an explanation" — you want the thinking to happen before the final answer is committed to.
Before answering, list the three strongest arguments on each side.
Then, in a final section labeled "Verdict", give your recommendation
in 2-3 sentences.This produces more defensible outputs because Claude has to surface counter-evidence before committing to a position, rather than rationalizing a quick answer after the fact.
Control Verbosity Explicitly
Claude models default to being thorough, which is great for analysis and bad for things like UI copy, commit messages, or API responses embedded in a product. If you don't constrain length and format, you'll get hedging, caveats, and unnecessary preambles like "Sure, here's..."
Fixes that work consistently:
- State a word or sentence limit directly: "Respond in exactly 2 sentences."
- Ban preambles explicitly: "Do not include any introductory phrase. Start directly with the content."
- Specify the output format precisely: "Return only valid JSON matching this shape: {...}"
- For API integrations, ask for a single format and nothing else, so you can parse the response without stripping boilerplate.
Use Few-Shot Examples for Format-Sensitive Tasks
When the exact output format matters — data extraction, classification labels, specific code style — one or two examples outperform a long written description of the format.
<example>
Input: "The checkout page crashes on mobile Safari."
Output: {"category": "bug", "severity": "high", "platform": "mobile"}
</example>
<example>
Input: "Can you add dark mode?"
Output: {"category": "feature_request", "severity": "low", "platform": "all"}
</example>
Input: "Search doesn't return results for queries with special characters."
Output:Two well-chosen examples usually beat five mediocre ones. Pick examples that cover edge cases you actually expect, not just the obvious case.
Iterate With the Same Test Set
Prompt engineering is empirical, not intuitive — a phrasing that sounds more precise to you doesn't always produce better output. Keep a small fixed set of representative inputs (5-10 is usually enough) and re-run them every time you change a prompt. Compare outputs side by side rather than relying on memory of "it seemed better."
If you're iterating through the API rather than a chat UI, streaming responses makes this loop faster since you see output as it's generated instead of waiting for the full completion — see /docs/streaming for implementation details.
Common Mistakes That Undermine Good Prompts
- Burying the instruction at the end of a long context block. Put the task instruction before large reference documents, or repeat it after, so it isn't lost in the middle.
- Mixing multiple unrelated tasks in one prompt. Split them into separate calls — Claude handles single, well-defined tasks more reliably than compound ones.
- Over-specifying tone with adjectives instead of examples. "Be professional but friendly" is vague; a one-line example of the target tone communicates more.
- Not testing with the exact model you'll ship with. Prompt behavior can shift between model versions, so re-validate prompts after switching models.
If you're building prompts into a product that other people or teams will call, routing those calls through an API layer like SubToAPI keeps your prompt templates and system prompts server-side, separate from client applications — useful once you have more than one app or team member hitting the same Claude access. Check /pricing for plan details or /docs/quickstart to get an API key running in minutes.
Questions
Does prompt engineering change between Claude model versions? Yes. Behavior around verbosity, instruction-following strictness, and formatting can shift between versions. Re-test your key prompts against a fixed example set whenever you upgrade models.
Should I use XML tags or markdown for structuring prompts? Both work, but XML tags are better for separating instructions from injected data (like user input or documents) because the boundaries are unambiguous. Markdown headings work well for structuring static, non-data prompt sections.
Why does Claude add unnecessary preamble to its answers? By default, Claude tends to be thorough and conversational. Explicitly instruct it to skip preambles and go straight to the requested output — this is one of the most effective single changes for API-integrated use cases.