You typed something into Claude, hit enter, and got back a wall of generic fluff that could have been written by literally any AI. Frustrating, right? Here’s the thing: the difference between a mediocre Claude response and one that genuinely blows your mind almost always comes down to how you wrote your prompt. Not what you asked for, but how you asked for it.
Claude is a different animal than most AI assistants you’ve used. It has its own quirks, its own strengths, and its own particular way of interpreting instructions. Once you understand those patterns, you’ll get dramatically better results with less back-and-forth. We’re going to cover the Claude-specific techniques that actually matter, from XML tags to few-shot examples to the subtle art of giving context that sticks.
Let’s get into it.
Why Claude Responds Differently to Prompts
Before we dive into techniques, you need to understand something fundamental: Claude was trained to follow instructions with unusual literalness. This is both a superpower and a trap.
If you tell Claude to “write a short paragraph,” you’ll get a short paragraph. Not three. Not a bulleted list with a paragraph tacked on. A short paragraph. Other models tend to “helpfully” over-deliver, throwing in extras you didn’t ask for. Claude respects your boundaries, which means your boundaries need to be well-defined.
This instruction-following precision means that vague prompts produce vague results, but specific prompts produce remarkably specific results. The model isn’t trying to guess what you “probably” meant. It’s doing what you said. That’s the hidden layer here: Claude rewards precision more than almost any other model you’ll work with.
The other thing worth knowing is that Claude has a strong preference for structured input. Where some models do fine with conversational stream-of-consciousness prompts, Claude really shines when you organize your thoughts. And the single most effective way to organize your thoughts for Claude? XML tags.
XML Tags: Claude’s Secret Weapon
This is the big one. If you take nothing else from this article, take this: XML tags are unreasonably effective with Claude.
Most people don’t use them because they feel “too technical” or unnecessary. But Claude was specifically trained to recognize and respect XML-style delimiters. When you wrap parts of your prompt in XML tags, Claude treats each section as a distinct, labeled block of information. The result is dramatically better instruction-following, cleaner outputs, and fewer hallucinations.
Here’s what this looks like in practice.
Bad Prompt vs. Good Prompt: The XML Difference
The bad prompt:
I need you to summarize this article about renewable energy. The article talks about
solar panel efficiency improvements in 2025, new battery storage technologies, and
government incentives. I want the summary to be about 200 words and written for a
general audience. Also include 3 key takeaways at the end.
This isn’t terrible. You’ll get something usable. But watch what happens when we restructure it with XML tags:
The good prompt:
<role>You are a science journalist who explains complex topics in plain language.</role>
<task>Summarize the following article about renewable energy developments.</task>
<article>
The article covers three main areas:
1. Solar panel efficiency improvements in 2025
2. New battery storage technologies
3. Government incentives for renewable adoption
</article>
<requirements>
- Length: approximately 200 words
- Audience: general readers, no technical jargon
- Tone: informative but accessible
- End with exactly 3 key takeaways as a bulleted list
</requirements>
<format>
Write the summary as a single block of prose, then add a "Key Takeaways" section
with 3 bullet points.
</format>
The difference in output quality is night and day. With the XML version, Claude knows exactly what its role is, what the task is, what the source material covers, what the constraints are, and how to format the output. There’s zero ambiguity. Every section has a label, and Claude processes each one distinctly.
Why does this work so well? Claude’s training included extensive exposure to structured markup. When it sees XML tags, something clicks internally — the model switches into a more precise, section-aware processing mode. It’s not just reading your text linearly; it’s parsing your intent structurally. That’s a huge difference.
Tags You Should Know
Here are the XML tags that produce the best results with Claude:
<role>or<system>— Define who Claude should be<task>or<instructions>— What you want done<context>— Background information Claude needs<examples>— Few-shot demonstrations (more on this below)<constraints>or<requirements>— Rules and boundaries<format>or<output_format>— How the response should look<input>or<document>— The content Claude should process
You can nest them, combine them, and invent your own. Claude doesn’t care about the specific tag names — it cares about the structure. Even <stuff_to_think_about> works perfectly fine. The tags are semantic labels for you as much as they are structural cues for Claude.
System Prompts and Instruction Formatting
If you’re using the Claude API (or any interface that supports system prompts), there’s a hierarchy to understand. The system prompt sits above your user message, and Claude treats it as foundational context — like the “rules of the world” for the conversation.
Here’s the practitioner knowledge that most guides skip: Claude follows system prompt instructions more strictly than user message instructions. If there’s a conflict between the two, the system prompt usually wins. This means you should put your most important behavioral instructions in the system prompt and your task-specific details in the user message.
A well-structured system prompt might look like this:
<system>
You are a senior Python developer with 15 years of experience. You write clean,
well-documented code following PEP 8 conventions.
<rules>
- Always include type hints in function signatures
- Add docstrings to every function
- Prefer list comprehensions over map/filter when readable
- If a question is ambiguous, ask for clarification rather than guessing
- Never use deprecated library features
</rules>
<style>
- Explain your reasoning before writing code
- Use comments sparingly -- code should be self-documenting
- When showing alternatives, explain the trade-offs
</style>
</system>
Notice how even within the system prompt, we’re using XML tags to separate concerns. The <rules> section tells Claude what to always do, and the <style> section tells Claude how to communicate. Clean separation, clean results.
A common mistake: People dump everything into the system prompt and leave the user message as a one-liner. Don’t do that. The system prompt should be stable context — things that won’t change between messages. The user message should be the variable part — the specific task or question for this interaction.
Few-Shot Examples: Show, Don’t Just Tell
Few-shot prompting is the technique of showing Claude examples of what you want before asking it to produce output. And honestly, it’s the single most underused technique by beginners.
Here’s why few-shot examples are so powerful with Claude specifically: Claude is extremely good at pattern matching from examples. Sometimes eerily good. You can show it two or three examples of input-output pairs, and it will not only replicate the pattern but generalize it correctly to new inputs. It picks up on formatting, tone, level of detail, edge case handling — all from your examples.
Few-Shot Prompting Pattern
<task>
Classify customer support tickets into categories and priority levels.
</task>
<examples>
<example>
<input>My account has been charged twice for the same order #4521. I need a refund
for the duplicate charge immediately.</input>
<output>
Category: Billing
Priority: High
Summary: Duplicate charge on order #4521, customer requesting immediate refund.
Action: Escalate to billing team for refund processing.
</output>
</example>
<example>
<input>Hey, just wondering if you guys have any plans to add dark mode to the
mobile app? Would be great for nighttime use.</input>
<output>
Category: Feature Request
Priority: Low
Summary: Customer requesting dark mode for mobile application.
Action: Log in feature request tracker, send acknowledgment.
</output>
</example>
<example>
<input>I can't log into my account. I've tried resetting my password three times
and it keeps saying "invalid token." I have a presentation in 2 hours and all my
files are in there.</input>
<output>
Category: Access/Authentication
Priority: Critical
Summary: Customer locked out due to password reset failure (invalid token),
time-sensitive need.
Action: Immediate escalation to authentication team, provide temporary access
if possible.
</output>
</example>
</examples>
<new_ticket>
I purchased the annual plan last month but I'm only seeing features from the free
tier. My account page shows "Free Plan" even though I have the receipt.
</new_ticket>
Classify this ticket following the exact format shown in the examples.
Look at how much information those three examples encode without a single explicit rule. Claude picks up:
- The four-field output format (Category, Priority, Summary, Action)
- How to calibrate priority (billing issues are High, feature requests are Low, time-sensitive access issues are Critical)
- The appropriate length and tone for summaries
- The style of action items
You could write a 500-word specification describing all of this, or you could show three examples. The examples are faster to write, easier for Claude to process, and produce more consistent results. That’s the trade-off you should almost always take.
How Many Examples Do You Need?
For most tasks, 2-3 examples are the sweet spot. Here’s the breakdown:
- 1 example: Shows the format, but Claude may not generalize well to edge cases
- 2-3 examples: Shows the format AND the variation, which is what you want
- 5+ examples: Diminishing returns, and you’re eating into your context window
The key is making your examples diverse. Don’t show three nearly identical inputs. Show the range — easy cases, hard cases, edge cases. Claude learns from the differences between examples as much as from the examples themselves.
Context Is Everything (And Most People Ignore It)
Here’s a prompting mistake I see constantly: people ask Claude to do something without giving it the context it needs to do it well. They’ll say “write me a marketing email” without mentioning the product, the audience, the tone, or the goal. Claude will write a marketing email, sure, but it’ll be generic because you gave it nothing specific to work with.
Claude’s context window is massive — we’re talking about 200K tokens on most models. Use it. Don’t be stingy with context. In fact, more relevant context almost always produces better results with Claude. This is one area where Claude genuinely differs from some other models that can get confused or distracted by long inputs.
Here’s what good context looks like:
<context>
Company: TechFlow (B2B SaaS, project management tool)
Target audience: Engineering managers at mid-size companies (100-500 employees)
Product being promoted: New "Sprint Analytics" feature
Previous campaign performance: Technical, data-driven emails perform 2x better
than emotional/story-driven ones for this audience
Brand voice: Professional but not stuffy, use "you/your" language, avoid buzzwords
Goal: Drive free trial signups for Sprint Analytics
</context>
<task>
Write a marketing email subject line and body (under 250 words) promoting
Sprint Analytics to our target audience.
</task>
See how the context does the heavy lifting? Claude now knows the company, the audience, what works historically, the voice, and the goal. The resulting email will be dramatically more targeted than a zero-context prompt.
The hidden layer here: Claude has a tendency to weight context that appears earlier in the prompt more heavily than context that appears later. If you have critical information, put it near the top. This isn’t a hard rule — Claude will use information from anywhere in the prompt — but in practice, front-loading your most important context produces slightly better results.
Common Prompting Mistakes (And How to Fix Them)
Let’s run through the mistakes I see most often. These are the low-hanging fruit — fix these and your Claude experience improves overnight.
Mistake 1: Being Vague About Format
Bad: “Give me some ideas for blog posts about AI.”
Good: “Give me 10 blog post ideas about AI in healthcare. For each idea, provide: a title (under 60 characters), a one-sentence hook, and the target audience. Format as a numbered list.”
The bad prompt could produce anything from a bulleted list of 3 ideas to a 5-paragraph essay about AI content strategy. The good prompt will produce exactly what you need, every time.
Mistake 2: Not Specifying What to Avoid
Claude follows instructions literally, but it can only follow instructions you actually give. If there’s a behavior you don’t want, say so explicitly.
<constraints>
- Do NOT include a conclusion or summary section
- Do NOT use the phrases "in today's world" or "it's important to note"
- Do NOT exceed 500 words
- If you're unsure about a technical detail, say so rather than guessing
</constraints>
Negative instructions are surprisingly powerful with Claude. While some models struggle with “don’t do X” (and do X anyway), Claude is genuinely good at respecting negative constraints. Use them freely.
Mistake 3: Ignoring the Context Window
You have 200K tokens. That’s roughly 150,000 words — an entire novel. If you’re asking Claude to analyze a document, paste the whole document. If you’re asking it to write code that fits into an existing codebase, include the relevant files. If you’re asking it to match a writing style, include samples.
People try to “save tokens” by paraphrasing their source material or describing it vaguely. This almost always backfires. Claude does its best work when it has the actual source material, not your summary of it.
Mistake 4: One Mega-Prompt vs. Iterative Refinement
Sometimes the best prompting strategy is not to write one perfect prompt, but to have a conversation. Start with a solid first prompt, review the output, then refine.
This works particularly well with Claude because of its strong conversational memory within a session. You can say “That’s good, but make the tone more casual and cut the second paragraph” and Claude will make exactly those changes without losing the rest of the context.
Mistake 5: Not Using Prefills (API Users)
If you’re using the Claude API, you can “prefill” Claude’s response — essentially starting its output for it. This is incredibly useful for controlling format:
{
"messages": [
{
"role": "user",
"content": "Analyze the sentiment of this review: 'The product is okay but shipping was terrible'"
},
{ "role": "assistant", "content": "Sentiment Analysis:\n- Overall:" }
]
}
By starting Claude’s response with “Sentiment Analysis:\n- Overall:”, you’ve locked in the output format. Claude will continue from where you left off. This technique is gold for structured outputs and is unique to the Claude API.
The Prompting Checklist
Before you hit send on any important prompt, run through this quick list:
- Role: Did you tell Claude who it should be?
- Context: Does Claude have the background information it needs?
- Task: Is the actual request crystal clear?
- Format: Did you specify how the output should look?
- Constraints: Did you set boundaries (length, tone, things to avoid)?
- Examples: Would a few-shot example make the task clearer?
- Structure: Are you using XML tags to organize complex prompts?
You don’t need all seven for every prompt. A simple question doesn’t need XML tags and few-shot examples. But for anything important — anything you’d be annoyed to have to re-do — hitting most of these points will save you time and frustration.
Putting It All Together: A Real-World Example
Let’s build a production-quality prompt from scratch. Say you need Claude to review code for security vulnerabilities.
The beginner approach:
Review this code for security issues:
[paste code]
You’ll get something. It’ll be surface-level.
The practitioner approach:
<role>
You are a senior application security engineer conducting a code review.
You specialize in OWASP Top 10 vulnerabilities and have deep experience
with Python/Django web applications.
</role>
<context>
This is a Django REST API endpoint that handles user authentication.
It's deployed behind an nginx reverse proxy and serves a React frontend.
The application handles sensitive financial data.
</context>
<task>
Review the following code for security vulnerabilities. For each issue found:
1. Identify the vulnerability type (reference OWASP category if applicable)
2. Explain WHY it's dangerous (not just what it is)
3. Provide a fixed code snippet
4. Rate severity as Critical/High/Medium/Low
</task>
<constraints>
- Focus on security issues only, not code style or performance
- If the code looks secure in a particular area, don't invent problems
- Prioritize findings by severity
- Be specific about attack vectors
</constraints>
<code>
[paste your code here]
</code>
The difference between these two prompts is the difference between a junior dev glancing at your code and a senior security engineer doing a thorough audit. Same model. Same code. Wildly different results. The only variable is the prompt.
Summary and What to Explore Next
Here’s the short version of everything we covered:
- XML tags are your best friend with Claude. Use them to structure any prompt longer than a sentence or two.
- Few-shot examples teach Claude patterns faster and more reliably than written specifications.
- Context is cheap (you have 200K tokens) and high-impact. Include more than you think you need.
- Be specific about format, constraints, and what to avoid. Claude follows instructions literally, so make your instructions worth following.
- System prompts are for stable behavioral instructions; user messages are for variable task details.
- Iterate when needed. Claude’s conversational memory is strong. Use it.
If you want to go deeper, explore Claude’s extended thinking feature for complex reasoning tasks, prefill techniques for structured API outputs, and prompt chaining for multi-step workflows. Each of these builds on the fundamentals we covered here and unlocks even more powerful patterns.
Now go rewrite your worst prompt using XML tags and watch what happens. I think you’ll be pleasantly surprised.