Claude Prompt Engineering: Techniques and Best Practices

A Fortune 500 company working with Anthropic improved customer-facing chat accuracy by 20% after switching from generic prompting patterns to three Claude-specific techniques: scratchpad reasoning, targeted few-shot examples, and prompt chaining. The gains came not from writing longer prompts but from structuring them to match how Claude processes information.

Claude handles prompts differently from other large language models in ways that matter for production systems. It treats XML tags as first-class structural markers, not just text. It calibrates reasoning depth dynamically through an effort parameter rather than requiring manual token budgets. Its latest models, including Opus 4.8, Sonnet 4.6, and Fable 5, follow system prompts more literally than earlier generations. Prompts tuned for GPT-4 or Gemini often produce unexpected results when used with Claude without adaptation.

The broader discipline has split into two tracks. Casual prompting, where you write a question and get a good answer, keeps getting easier as models improve at reading intent. Production prompt engineering, what Anthropic's engineering team now calls context engineering, has become a real engineering skill. It covers not just the prompt text but everything in the context window: system instructions, tool definitions, retrieved data, conversation history, and state management across turns.

This guide covers both levels. You will find six core techniques from Anthropic's official documentation, then the context engineering patterns that matter when Claude runs inside agent workflows.

Anthropic's official prompt engineering documentation organizes techniques into a clear hierarchy. These six form the foundation, ordered from simplest to advanced.

1. Be clear and direct

Claude responds best to explicit instructions with specific constraints. Anthropic's golden rule: show your prompt to a colleague who has no context on the task. If they would be confused, Claude will be too. Instead of "Create an analytics dashboard," try "Create an analytics dashboard with user segmentation, date range filtering, and CSV export. Include interactive charts." The more precise you are about output format, content scope, and boundaries, the closer the result matches your intent. Provide instructions as sequential numbered steps when order matters.

2. Use XML tags for structure

XML tags help Claude parse complex prompts without ambiguity. Wrap different types of content in descriptive tags like <instructions>, <context>, <examples>, and <input>. Claude treats these as semantic boundaries, which reduces the chance of it mixing up your instructions with your data. Nested tags work well for document hierarchies, and consistent tag naming across your prompts builds a shared vocabulary that Claude quickly adapts to. This is one of the techniques where Claude diverges most from GPT-style prompting, where markdown headers typically fill the same role.

3. Provide few-shot examples

Three to five well-chosen examples are one of the most reliable ways to steer Claude's output format, tone, and structure. Wrap them in <example> tags so Claude distinguishes them from instructions. Make examples diverse: cover edge cases and vary formats enough that Claude picks up the right patterns rather than overfitting to a single style. You can also ask Claude to evaluate your examples for relevance and diversity, or to generate additional ones based on your initial set. Think of examples as compressed specifications. They communicate format, tone, and edge case handling faster than written rules.

4. Assign a role through the system prompt

A single sentence in the system prompt focuses Claude's behavior and vocabulary. "You are a senior Python engineer who writes production-grade, well-tested code" produces materially different output than a generic prompt. Roles activate domain-specific knowledge and set appropriate defaults for detail level, tone, and terminology. For production applications, combine roles with explicit constraints: "You are a financial analyst. Only cite data from the provided documents. Flag any figures you cannot verify." Test different role definitions against your evaluation set and you will likely see meaningful accuracy differences.

5. Configure adaptive thinking

Claude 4.6 and newer models use adaptive thinking, where the model dynamically decides when and how deeply to reason based on the effort parameter and query complexity. The effort levels are low, medium, high, xhigh, and max. Higher effort triggers more internal reasoning for complex tasks. Lower effort produces faster responses for simple queries. In Anthropic's internal evaluations, adaptive thinking consistently outperforms the older manual budget_tokens approach. For most API workloads, start with "high" and adjust based on your latency and accuracy requirements.

6. Chain prompts for complex tasks

Break multi-step reasoning into separate API calls when you need to inspect intermediate outputs or enforce a specific processing pipeline. The most practical chaining pattern is self-correction: generate a draft, send it back with evaluation criteria to identify problems, then produce a revised version incorporating the feedback. Each step is a distinct API call, so you can log results, run quality checks, or branch your pipeline at any point. With adaptive thinking and sub-agent orchestration in newer models, explicit chaining is primarily useful when you need that inspection checkpoint between stages.

The simplest XML structuring pattern separates your instruction from your data:

<instructions>
Summarize the following document in three bullet points.
Focus on actionable findings only.
</instructions>

<document>
{{DOCUMENT_CONTENT}}
</document>

For multi-document tasks, add indexing and metadata. Anthropic's testing shows that placing long documents above the query, with instructions at the bottom, improves response quality by up to 30%.

<documents>
  <document index="1">
    <source>quarterly_report.pdf</source>
    <document_content>
    {{REPORT}}
    </document_content>
  </document>
  <document index="2">
    <source>market_analysis.xlsx</source>
    <document_content>
    {{ANALYSIS}}
    </document_content>
  </document>
</documents>

Compare the quarterly results against the market analysis.
Identify three areas where performance diverged from projections.

Few-shot examples follow the same tag convention. Wrap each example in <example> tags and the full set in <examples>:

<examples>
  <example>
    <input>Revenue: $4.2M, up 18% YoY</input>
    <output>Revenue grew 18% year-over-year to $4.2M.</output>
  </example>
  <example>
    <input>Churn: 3.1%, down from 4.8%</input>
    <output>Churn dropped to 3.1%, a 35% improvement.</output>
  </example>
</examples>

<input>{{NEW_DATA}}</input>

One pattern that trips up developers new to Claude: the model generalizes aggressively from examples. If all your examples are short, Claude writes short. If they all use bullet points, Claude defaults to bullets. Build variety into your examples on purpose. Include at least one edge case and vary the output length across your set.

For prompts exceeding 20,000 tokens, a grounding technique makes a measurable difference. Ask Claude to quote relevant passages from the source material before answering. This forces the model to locate evidence rather than generating from its training data.

<document>
{{LONG_DOCUMENT}}
</document>

First, find and quote the passages most relevant to the
question below. Place them in <quotes> tags. Then answer
based only on those quotes.

Question: {{USER_QUESTION}}

A practical note on tag naming: use descriptive, lowercase names that match your domain vocabulary. <customer_feedback> works better than <data> or <input_1>. Claude uses tag names as semantic hints, so meaningful names produce better results even before the model reads the content inside them. For production systems, keep your tag vocabulary consistent across all prompts in a project.

When migrating existing prompts to use XML structure, start with the input/output boundary. Wrap your variable data in tags first (<input>, <document>, <user_query>), then separate your instructions into an <instructions> block. This single change often improves consistency more than rewriting the instruction text itself.

Give your Claude agents a persistent workspace

50GB free storage with MCP-native access for file operations, RAG queries, and human handoffs. No credit card required.

Sign Up Free

Claude 4.6 and Claude Sonnet 4.6 replaced the older extended thinking system with adaptive thinking. Instead of setting a manual budget_tokens cap, the model now decides when to reason internally based on two signals: the effort parameter you configure and the complexity of the query.

Here is the API configuration for adaptive thinking:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[
        {
            "role": "user",
            "content": "Review this pull request for security issues."
        }
    ],
)

The effort levels are low, medium, high, xhigh, and max. For most API calls, "high" provides a good balance between reasoning quality and response time. Use "low" for fast classification and lookup tasks. Reserve "max" for complex analysis where accuracy matters more than latency.

Adaptive thinking behavior is promptable. If Claude is thinking too much on simple queries, add guidance to your system prompt: "Only use extended reasoning for problems that require multi-step analysis. For straightforward questions, respond directly." If Claude is not thinking enough on hard problems, raise the effort level rather than adding more "think step by step" language to the prompt.

Prompt chaining becomes especially effective when combined with thinking. The standard self-correction pattern works in three API calls:

1. Generate a draft with thinking enabled at effort "high"
2. In a separate call, send the draft back with evaluation criteria and ask Claude to list specific problems
3. Send the critique back and ask Claude to produce a revised version

Each step is a checkpoint where you can log outputs, run automated quality checks, or route the pipeline. For production systems, step two often catches issues that would otherwise require a human reviewer, making the extra API call worth the latency.

For developers migrating from extended thinking with budget_tokens, the change is straightforward. Replace thinking: {"type": "enabled", "budget_tokens": 32000} with thinking: {"type": "adaptive"} and move budget control to the effort parameter. If you need a hard ceiling on total output tokens, use max_tokens as a backstop.

Anthropic recommends starting with a minimal prompt on a capable model, then adding instructions only when you observe specific failure modes. This avoids over-prompting, where too many competing rules suppress Claude's base capabilities rather than guiding them. If your prompts previously included aggressive language like "CRITICAL: You MUST use this tool when..." to compensate for undertriggering in older models, dial that back. Claude 4.6 models respond better to natural phrasing like "Use this tool when it would help."

Context engineering extends prompt engineering from single-turn interactions to multi-turn agent systems. Anthropic defines it as "strategies for curating and maintaining the optimal set of tokens during LLM inference." The distinction matters because agents face a problem that individual prompts do not: context rot. As token count grows in a conversation, the model's accuracy at recalling specific information from that context decreases. The transformer architecture's pairwise attention means more tokens create more noise competing for signal.

Three patterns from Anthropic's engineering team address this directly.

Just-in-time retrieval keeps the context window lean by storing lightweight identifiers (file paths, search queries, URLs) and loading full data only when the agent needs it. This mirrors how people work: you remember where a document lives, not every sentence in it. In practice, give agents search and file-reading tools rather than stuffing all reference material into the system prompt. Claude Code uses this pattern with CLAUDE.md files loaded upfront for critical context while glob and grep tools handle on-demand file discovery.

Compaction summarizes long conversations when they approach the context limit. The agent extracts key decisions, results, and remaining tasks, then reinitializes with the compressed summary. The lightest approach is clearing verbose tool outputs while keeping the agent's reasoning trail intact. Anthropic's newer models also feature context awareness, where the model tracks its remaining token budget and can save progress before a context refresh.

Sub-agent architectures delegate focused tasks to specialized agents with clean context windows. Each sub-agent handles one narrow job, like searching a codebase or analyzing a dataset, and returns a condensed summary of 1,000 to 2,000 tokens. The lead agent stays focused on coordination rather than drowning in raw data. Claude Opus 4.6 has strong native sub-agent orchestration and will delegate proactively when it recognizes a task would benefit from parallel processing.

For teams building agent workflows, the workspace where agents store and retrieve files is part of the context engineering strategy. Local file systems work for single-developer setups. Object storage like S3 handles raw persistence at scale. Platforms like Fast.io add automatic semantic indexing on top: files uploaded to a workspace are indexed through Intelligence Mode, so an agent can query "find the contract clause about liability limits" instead of scanning files sequentially. The Fast.io MCP server exposes workspace, storage, and AI operations through Streamable HTTP at /mcp, giving Claude agents access to file operations, RAG queries with citations, and workflow tools without custom infrastructure. The free agent plan includes 50GB of storage, 5,000 credits per month, and 5 workspaces, with no credit card and no expiration.

The core principle stays the same regardless of tooling: treat your agent's context as a finite resource. Find, as Anthropic's engineering team puts it, "the smallest set of high-signal tokens that maximize the likelihood of your desired outcome." Well-designed tools with clear descriptions and minimal overlap reduce the tokens spent on tool definitions. Structured state files (JSON for test results, plain text for progress notes) give agents cheap ways to persist and recover context across sessions. As models grow more capable, which tokens you choose to include matters more than how many you can fit.