Claude Prompting Best Practices: A Practical 2026 Guide

Claude’s current models follow instructions closely. That’s good news: a clear, well-structured prompt gets you a lot further than it used to, and vague prompts get you exactly what you asked for, which is often not what you wanted. This guide distils Anthropic’s official prompting guidance (current as of October 2026, covering models such as Claude Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5) into techniques you can apply today, in claude.ai, the API or Claude Code.

Before you write the prompt

Anthropic’s prompt engineering overview starts with three prerequisites:

1. A clear definition of success criteria for the task.
2. Some way to test against those criteria.
3. A first draft prompt to improve.

Without the first two, you can’t tell whether a prompt change helped. Even for personal use, keep two or three real inputs around and rerun them when you edit an important prompt.

Also note that not every problem is a prompting problem. Latency and cost, for example, are often better solved by choosing a different model or effort level; our Claude API pricing guide compares per-token costs by model.

1. Be clear and direct

Treat Claude like a brilliant new colleague who has no context on your norms. Anthropic’s test: show the prompt to a colleague with minimal context. If they’d be confused, Claude will be too.

• State the output format and constraints explicitly.
• Use numbered steps when order or completeness matters.
• If you want more than the bare minimum, ask for it.

Less effective:
Create an analytics dashboard

More effective:
Create an analytics dashboard. Include as many relevant features and
interactions as possible. Go beyond the basics to create a fully-featured
implementation.

The same applies to action. “Can you suggest some changes to improve this function?” often gets suggestions. “Change this function to improve its performance” gets changes.

2. Explain why

Context and motivation help Claude generalise. Compare:

Less effective:
NEVER use ellipses

More effective:
Your response will be read aloud by a text-to-speech engine, so never use
ellipses since the text-to-speech engine will not know how to pronounce them.

With the reason, Claude can also avoid other things a text-to-speech engine would stumble on, without you listing them all.

3. Use examples (few-shot prompting)

Examples are one of the most reliable ways to steer format, tone and structure. Make them:

• relevant, mirroring your real use case;
• diverse, covering edge cases so Claude doesn’t copy an accidental pattern;
• structured, wrapped in example tags (several inside an examples tag).

Anthropic suggests three to five examples for best results. You can ask Claude to critique your examples or generate more from your initial set.

4. Structure prompts with XML tags

When a prompt mixes instructions, context, examples and inputs, tags keep them unambiguous:

<context>
We're a B2B SaaS company. The reader is a non-technical operations manager.
</context>

<instructions>
Summarise the incident report below in under 150 words.
Lead with customer impact, then cause, then next steps.
</instructions>

<incident_report>
{{REPORT_TEXT}}
</incident_report>

Use consistent, descriptive tag names and nest them when content is hierarchical (each document inside a documents tag). The names themselves aren’t magic.

5. Give Claude a role

A role in the system prompt focuses behaviour and tone. Even one sentence helps:

You are a senior site reliability engineer reviewing a postmortem for a
fintech company. You care about blast radius, detection time and whether
action items are specific enough to be assigned.

The more specific the role and audience, the better Claude calibrates depth and vocabulary.

6. Long documents: data first, question last

For large inputs (roughly 20,000+ tokens):

• Put the long documents at the top, above your instructions and question. Anthropic’s tests found queries at the end can improve response quality by up to 30%, especially with multiple documents.
• Wrap each document with its metadata:

<documents>
  <document index="1">
    <source>annual_report_2025.pdf</source>
    <document_content>
      {{ANNUAL_REPORT}}
    </document_content>
  </document>
  <document index="2">
    <source>competitor_analysis.xlsx</source>
    <document_content>
      {{COMPETITOR_ANALYSIS}}
    </document_content>
  </document>
</documents>

Analyze the annual report and competitor analysis. Identify strategic
advantages and recommend focus areas for next quarter.

• Ask for quotes first. For long-document tasks, have Claude extract relevant quotes into a quotes tag before answering. It focuses the model on what matters and makes the answer easy to verify.

7. Control the output format

Four techniques from the official guide:

1. Say what to do, not what not to do. Instead of “Do not use markdown”, try “Write your response as smoothly flowing prose paragraphs.”
2. Use XML format indicators. “Write the analysis inside analysis tags and the final recommendation inside recommendation tags.”
3. Match your prompt’s style to the output you want. A prompt full of markdown tends to produce markdown; prose prompts nudge towards prose.
4. Be explicit about formatting preferences when they matter (when to use lists, headings, code blocks).

For machine-readable output in API apps, use the structured outputs feature rather than hoping for valid JSON.

Don’t rely on prefill

Older prompting advice suggested prefilling the start of Claude’s reply (for example an opening brace) to force a format. Starting with the Claude 4.6 models, prefilling the last assistant turn is no longer supported and returns a 400 error. Migrate to structured outputs, direct instructions (“Respond directly without preamble”) or XML output tags.

8. Thinking and effort

Current Claude models use adaptive thinking: Claude decides when and how much to reason. On some of the newest models thinking is always on. You can still steer it:

After receiving tool results, carefully reflect on their quality and determine
optimal next steps before proceeding.

If Claude overthinks simple tasks, tell it to choose an approach and commit, or lower the effort setting. Anthropic now recommends effort and max_tokens over the older budget_tokens thinking cap, which returns an error on Claude 4.7 and later models.

9. Prompting for agentic coding

These matter most in Claude Code and agent apps.

Ground answers in the code

<investigate_before_answering>
Never speculate about code you have not opened. If the user references a
specific file, you MUST read the file before answering. Make sure to
investigate and read relevant files BEFORE answering questions about the
codebase.
</investigate_before_answering>

Keep solutions minimal

Capable models sometimes over-engineer: extra files, abstractions, flexibility nobody asked for. If that happens:

Avoid over-engineering. Only make changes that are directly requested or
clearly necessary. Don't add features, refactor code, or make "improvements"
beyond what was asked. Don't create helpers or abstractions for one-time
operations.

Solve the problem, not the tests

Implement a solution that works correctly for all valid inputs, not just the
test cases. Do not hard-code values. If any of the tests are incorrect,
tell me rather than working around them.

Give it a verification loop

Anthropic’s Claude Code best practices put this first: give Claude a check it can run (tests, a build, a linter, a screenshot comparison) so it iterates until the check passes. “Write validateEmail; user@example.com is valid, user@.com is not; run the tests after implementing” beats “implement email validation”.

Clean up scratch files

If you create any temporary files, scripts, or helper files for iteration,
remove them at the end of the task.

10. Chain prompts when you need checkpoints

Claude handles most multi-step reasoning internally now, but explicit chaining still helps when you want to inspect intermediate results. The most useful pattern is self-correction: generate a draft, have Claude review it against explicit criteria, then refine. Each step is a separate call you can log and evaluate.

A reusable prompt template

<role>
You are a {{ROLE}} helping {{AUDIENCE}}.
</role>

<context>
{{BACKGROUND_AND_WHY_THIS_MATTERS}}
</context>

<input>
{{THE_MATERIAL_TO_WORK_ON}}
</input>

<instructions>
1. {{STEP_ONE}}
2. {{STEP_TWO}}
3. If information is missing or ambiguous, list your assumptions explicitly.
</instructions>

<output_format>
{{EXACT_SHAPE_OF_THE_ANSWER}}
</output_format>

Put long inputs above the instructions, keep variables in double braces so they’re easy to spot, and save prompts you reuse. In Claude Code, a reused prompt belongs in a skill, where $ARGUMENTS replaces the variables.

Ready-made prompts

Our prompt library applies these techniques to common jobs:

• Code review prompt: severity-ranked findings grounded in the diff.
• Bug triage prompt: reproduce, isolate, hypothesise.
• Refactor plan prompt: staged, reversible refactors.
• Unit test generator prompt: behaviour-focused tests with edge cases.
• Commit message prompt: Conventional Commits from a staged diff.
• Log analysis prompt: timeline and ranked root-cause hypotheses from production logs.
• API documentation prompt: endpoint docs derived from source code.
• PRD writer prompt, SQL explainer, blog outline and meeting notes to action items.

Common mistakes

• Negative-only instructions. “Don’t be verbose” is weaker than “Answer in at most three sentences.”
• Over-prompting. Lines like “If in doubt, use the search tool” were needed for older models and now cause over-triggering. Remove them and re-test.
• Mixing data and instructions. Untagged pasted text can be read as instructions. Tag it.
• One giant prompt for a multi-stage job. Break it up, or let Claude Code plan first.
• No test inputs. Without a few saved cases you can’t tell whether an edit helped.

Learn more

• Anthropic’s official prompting best practices on platform.claude.com, including model-specific pages.
• Anthropic’s interactive prompt engineering tutorial on GitHub (written for older models, so prefer the current docs where they differ).
• On this site: Getting started with Claude Code and What is a Claude kit?.