How to write better prompts for Claude (with examples)

title: How to write better prompts for Claude (with examples)

slug: how-to-write-better-prompts-claude description: Claude has specific formatting preferences that affect output quality. XML tags, explicit constraints, and structured context sections make Claude measurably better.

keywords: prompt template for Claude, how to write prompts for Claude, Claude prompt format, Claude XML prompt

author: Mariano

date: 2026-04-13

How to write better prompts for Claude (with examples)

Claude is trained on documents with XML structure. It parses XML tags more reliably than Markdown or plain text. This isn't secret knowledge — Anthropic documents it. But most people still write Claude prompts as plain paragraphs.

The difference in output quality is measurable. Better structure = better output. Here's exactly how to format prompts for Claude.

The XML structure Claude expects

Claude responds strongly to structure. XML tags carry semantic meaning. When you write:

<role>You are a senior technical writer specializing in API documentation.</role>
<context>The user is documenting a REST API with 50+ endpoints.</context>
<task>Write endpoint documentation for the POST /users endpoint.</task>
<output_format>Use OpenAPI 3.0 format with examples for each code language.</output_format>
<constraints>
- Maximum 200 words per endpoint description
- Include error responses for 400, 401, 403, 404, 500
- Use present tense
- Assume readers know HTTP basics
</constraints>

Claude immediately understands the boundary between each section. The tag names tell Claude what each section means. <role> = who I am. <context> = what I know about the domain. <task> = what you want me to do. <constraints> = hard boundaries I cannot cross.

Compare to plain text:

You are a senior technical writer. The user is writing API docs for a REST API
with 50+ endpoints. Write documentation for the POST /users endpoint. Use OpenAPI 3.0.
Keep descriptions under 200 words. Include error responses. Use present tense.

Claude can parse this. The output will be readable. But quality is lower because Claude has to infer the structure. Without tags, everything is just... text. There's no explicit signal about what's important.

Why XML works for Claude

Claude is trained on documents. Real documents. Academic papers, technical specs, books, code documentation. Documents use structure. They use headings, sections, labeled blocks.

Claude learned to parse this structure and use it to understand context. When you use XML tags, you're speaking Claude's native language.

XML tags are also unambiguous. A Markdown header like # Task could mean anything. A XML tag like <task> has one meaning.

Ambiguity kills output quality. Clarity enables it.

The 5 most impactful fields for Claude prompts

If you only structure five fields, these are the ones that matter most:

1. Role: who the AI is

Claude responds strongly to persona. The role definition calibrates everything downstream. It sets tone, expertise level, and how Claude approaches the task.

<role>You are a senior product manager at a B2B SaaS company with 10 years of experience scaling platforms.</role>

Versus:

<role>You are a product manager.</role>

The first one is much more useful. Claude understands the context: B2B (not B2C), SaaS (not physical products), senior level (10 years), scaling-focused. This changes how Claude approaches any subsequent task.

2. Context: domain knowledge

Context is how you download information into Claude. It's the domain knowledge Claude needs to calibrate its response.

For a code review task:

<context>
The application uses React 18 with TypeScript and connects to Supabase.
The team prioritizes performance and follows strict type safety practices.
Pull requests usually include 5-15 files with 100-500 lines of changes.
Code review must be constructive but direct.
</context>

Without this, Claude defaults to generic advice. With it, Claude gives feedback specific to your stack and practices.

3. Task: the actual instruction

The task should be a single, clear action. Not multiple things. One thing.

<task>Review the provided code changes for performance bottlenecks, type safety issues, and anti-patterns. Flag anything that could cause problems at scale.</task>

Versus:

<task>Review the code. Also suggest tests. Also check for security issues. Also check documentation. Also refactor any functions you think need it.</task>

The first is better. One clear job. Claude executes it better than juggling five things.

4. Output Format: what structure do you want back

Output format instructions are one of the highest-impact levers in prompt engineering. Claude follows format instructions precisely when they're explicit.

<output_format>
Return a JSON object with these fields:
- performance_issues: array of {severity: "high"|"medium"|"low", description, line_number}
- type_safety_issues: array of {severity: "high"|"medium"|"low", description, line_number}
- anti_patterns: array of {description, suggestion}
- summary: one-sentence summary of overall code quality
</output_format>

With explicit format, you get reliable, parseable output. Without it, Claude defaults to verbose prose. You get paragraphs. You get explanations. You get something that's hard to parse.

5. Constraints: hard boundaries

Constraints are different from instructions. Instructions say "do this." Constraints say "don't do that under any circumstances."

<constraints>
- Do NOT suggest refactoring code unless it has a clear performance or readability problem
- Do NOT suggest new frameworks, libraries, or architectural changes
- Do NOT praise code that is mediocre; only highlight genuinely good choices
- Do NOT exceed 500 words total
- Do NOT include code examples unless the suggestion is unclear without them
</constraints>

Constraints are respected by Claude. They're boundaries. Claude understands that constraints are non-negotiable.

Extended thinking: when to use thinking blocks

Claude supports <thinking> blocks for complex reasoning. Use them for:

Multi-step analysis. Code review with several layers of evaluation.

Comparison tasks. Evaluating multiple options and ranking them.

Debugging. Understanding why something is broken.

Architecture decisions. Weighing tradeoffs.

<thinking>
The user is asking me to review code. I should:
1. First understand what the code does
2. Check for performance issues (loops, database queries)
3. Check for type safety issues (any type casting)
4. Check for anti-patterns (this is the most subjective)
5. Synthesize into a summary

Let me work through this step by step.
</thinking>

Thinking blocks trigger deeper processing. Claude takes more time and explores the problem more thoroughly. For simple tasks (summarization, formatting), you don't need thinking. For complex analysis, thinking blocks improve quality noticeably.

Common mistakes to avoid

Mistake 1: Wall of text with no tags

Review this code for bugs and performance issues. It's a React component
that uses Supabase. Check for common anti-patterns. Make sure the types are right.
Try not to be too verbose but be thorough. Oh, and assume it's TypeScript.

Claude can parse this. But quality is lower because the structure is implicit, not explicit.

Mistake 2: Mixing instruction styles

Don't write some sections as XML and others as Markdown:

<role>Senior code reviewer</role>
<context>React + Supabase application</context>

## Task
Review the code for performance issues

**Constraints:**
- Keep feedback concise
- Be direct

Pick one style and commit to it. All XML or all Markdown. Mixed is confusing.

Mistake 3: Putting constraints inside the task

<task>
Review the code for performance issues. Don't praise mediocre code.
Be direct. Keep it under 500 words. Focus on real problems, not style nitpicks.
</task>

Better:

<task>Review the code for performance issues.</task>
<constraints>
- Do NOT praise mediocre code
- Be direct, not diplomatic
- Maximum 500 words
- Focus on real problems, not style
</constraints>

Constraints belong in a separate section. They're boundaries, not instructions.

Mistake 4: Not specifying output format

<task>Summarize this technical document.</task>

Claude will summarize. But what format? How long? What structure? Claude defaults to verbose prose.

<task>Summarize this technical document.</task>
<output_format>
Return a JSON object with:
- key_findings: array of strings, each under 50 words
- technical_details: object with relevant metrics, numbers, or specifications
- next_steps: array of recommended actions
- confidence_level: "high" | "medium" | "low" (how confident are you in this summary)
</output_format>

Now Claude knows exactly what you want. Output quality improves immediately.

A complete example: feature spec prompt

Before (plain text):

Write a feature spec for a new user onboarding flow. It should be
comprehensive but not too long. Think about the user experience
and what makes sense. Include success criteria or something like that.
Make it professional.

Output: Rambling, includes irrelevant sections, no clear structure, hard to extract what you need.

After (structured XML):

<role>
You are a senior product manager at a B2B SaaS company.
You've shipped dozens of onboarding flows. You understand both UX and technical constraints.
</role>

<context>
The product is a prompt engineering platform for teams.
Users are developers and product managers with 0-5 years AI/LLM experience.
Current onboarding is 8 steps. Users drop off at step 4.
New flow should be 4-5 steps maximum.
</context>

<task>
Write a feature spec for a streamlined user onboarding flow.
Focus on getting users to their first working prompt in under 5 minutes.
</task>

<output_format>
Return a structured spec with these sections:
- Overview (2-3 sentences)
- User journey (step-by-step, maximum 5 steps)
- Success criteria (measurable outcomes)
- Key design decisions (why each step exists)
- Edge cases (what happens if user skips/fails at each step)
- Technical requirements (any APIs or backend changes needed)
</output_format>

<constraints>
- Maximum 1000 words total
- Each step should take under 1 minute
- Focus on critical path only; don't include optional features
- Spec should be actionable for design and engineering
- Do NOT include detailed UI mockups; describe interaction, not pixels
</constraints>

Output: Structured, complete, exactly what you asked for. Clear sections. Actionable.

The difference is night and day. The structured version takes slightly longer to write upfront. The output quality makes up for it immediately.

How prompt-x compiles for Claude

prompt-x stores prompts in a canonical 9-field format. When you compile for Claude, it automatically:

Wraps each field in XML tags
Uses <role>, <context>, <task>, <tone>, <output_format>, <constraints>
Adds optional <thinking> blocks for complex tasks
Formats examples as XML as well

You write once, in structured fields. Compile for Claude, and you get perfect XML formatting automatically.

Compile for GPT-4, and you get Markdown headers. Compile for Gemini, and you get label format. Same source. Different outputs.

This is the professional approach: structure your prompt once, deploy everywhere.

The takeaway

Claude is extraordinarily powerful. The quality difference between a wall of plain text and a structured XML prompt is massive. But most people don't use XML. They leave a real share of Claude's output quality on the table because of formatting alone.

Use XML tags. Be explicit about role, context, task, output format, and constraints. Test with and without structure. You'll see the difference immediately.

prompt-x handles Claude formatting automatically. Write your prompt in the 9-field editor. Compile for Claude XML with one click. The formatting is perfect, the structure is maintained, and you can version-control the whole thing.

The platform compiles the same source to GPT-4 Markdown, Gemini labels, and Claude API XML. Write professional prompts once. Deploy everywhere they're needed.

Try it free

Related reading