You’re Prompting Claude Wrong: Anthropic’s Official Prompt Engineering Guide

If Claude keeps returning generic prose, the usual fix is not a clever incantation. “Analyze this deeply,” “be professional,” and “do your best” express ambition without defining the job. Claude still has to guess who will use the answer, which evidence matters, what shape the result should take and when the task is complete.

Anthropic's own framing is useful: treat Claude like a highly capable new employee who does not know your workflow. If a colleague with little context could not execute your prompt consistently, neither can the model. Prompt engineering is therefore closer to writing a good brief than discovering magic words.

Your prompt asks a question but leaves the decisions to Claude

Consider “Review this strategy and write a professional report.” It leaves the audience, business objective, source boundary, decision criteria, length and structure undefined. A fluent answer can still be the wrong answer because the model made six product decisions on your behalf.

10 Claude prompt-engineering practices Anthropic actually recommends

1. Write the acceptance criteria, not “do your best”

Name the audience, deliverable, length, required elements and exclusions. If order matters, use numbered steps. Replace “summarize this” with “write five bullets for an executive who has two minutes; separate revenue impact from operational risk.”

2. Explain why a constraint exists

Context helps Claude generalize when the input does not match your happy path. “Use short sentences because this will be read on a phone during field work” carries more intent than “use short sentences.”

3. Use three to five relevant, varied examples

Examples are among the most dependable controls for format, tone and classification boundaries. Anthropic recommends examples that resemble the real task, cover meaningful edge cases and use a consistent structure. A single example can accidentally teach irrelevant quirks.

4. Give each kind of information an XML boundary

When instructions, reference material, examples and live input share one block, their roles can blur. Descriptive tags such as <instructions>, <context>, <examples> and <input> make the boundaries explicit. The tag names matter less than using them consistently.

5. Define a role by its priorities

“You are a marketer” is mostly cosmetic. “You optimize B2B SaaS acquisition for qualified pipeline and revenue, not raw clicks” establishes a decision rule. Put persistent role and behavior instructions in the system prompt when using the API.

6. Put long documents before the query

For data-rich prompts above roughly 20,000 tokens, Anthropic recommends placing the source documents near the top, followed by the query and instructions. Its documentation reports that moving the query to the end improved answer quality by up to 30% in tests involving complex, multi-document input.

7. Describe the output you want in positive terms

“Lead with the conclusion and limit supporting evidence to three bullets” is more actionable than “do not ramble.” Current Claude models also follow scope literally: if a format applies to every section, say so instead of assuming the model will generalize it.

8. Use effort controls before prompt theatrics

Current Claude API models use adaptive thinking and model-specific effort controls. When a difficult coding or agent task is under-reasoned, raising effort is the first lever. Repeating “think very deeply” cannot reliably compensate for a latency-oriented setting, and excessive verification language can waste tokens on capable models.

9. Tell Claude when tools are mandatory

Tool availability is not a complete tool policy. Say when current information requires search, when a named file must be opened before answering, or when a calculation must be checked with code. A grounded coding rule can be as simple as: never make a claim about code you have not inspected.

10. Add a narrow verification step

Ask Claude to check the result against concrete criteria: source numbers, schema validity, test cases or omitted requirements. Avoid a generic instruction to verify everything repeatedly. Newer top-tier models can over-verify when old prompts keep pushing them to recheck work they already validated.

From vague request to executable brief

Weak prompt: “Analyze this material like an expert and write a great report. Do not make mistakes. Think deeply.”

“Expert,” “great,” and “deeply” have no testable meaning. A better version assigns the missing decisions:

<role>
You are a strategy analyst reviewing B2B SaaS unit economics.
Prioritize cash flow and customer-acquisition efficiency over headline growth.
</role>

<context>
The CFO will use this in next quarter's budget meeting.
</context>

<instructions>
1. Separate source facts from your interpretation.
2. Calculate quarter-over-quarter changes.
3. Identify the three largest risks and a response to each.
4. Do not estimate numbers missing from the source.
</instructions>

<output_format>
Three-sentence conclusion, KPI table, risks and responses, missing information.
</output_format>

<source>
...source material...
</source>

Write the CFO briefing using the criteria above.

A reusable Claude prompt template

<role>
[Expert role and its decision priorities]
</role>

<goal>
[Who will use the output, and what decision will it support?]
</goal>

<context>
[Background, constraints, and definitions]
</context>

<instructions>
1. [Required action]
2. [Evidence rule]
3. [When to ask, stop, or exclude]
</instructions>

<examples>
[Three to five representative input/output examples]
</examples>

<output_format>
[Order, length, tables, fields, and voice]
</output_format>

<verification>
[Specific checks before completion]
</verification>

<input>
[Live task material]
</input>

Do not fill every block by habit. A one-line lookup does not need eight XML sections. Use structure where a boundary could be misunderstood or an important choice would otherwise be guessed.

The best-practices page is only half the documentation

Anthropic now publishes model-specific prompting pages because initiative, literal instruction following, tool use, thinking defaults and self-verification change between releases. A prompt tuned to force an older model through every step may cause a newer model to expand scope or verify excessively.

Keep role, task, examples and output contracts as reusable prompt assets. Treat effort, thinking, tool triggers and progress-update behavior as model configuration that must be retested during migration. That separation makes prompts easier to maintain than one giant block full of historical fixes.

The real rule: stop making Claude guess

Prompt engineering is not about manipulating a model with secret phrases. It is the discipline of defining who needs the result, what decision it supports, which evidence is allowed and what completion looks like. Examples and verification make that contract repeatable.

Before adding “think harder,” check four things: Is the goal visible? Are source material and instructions separated? Have you shown a representative output? Can completion be tested? Most bad Claude prompts fail one of those checks.

Frequently asked questions