Prompt engineering for Claude is not a collection of secret commands. It is a disciplined process for making the intended behavior observable: what success means, which inputs vary, what context Claude should use, and how the result will be evaluated.
Anthropic’s official overview assumes three things before optimization begins: a clear definition of success, a way to test against it, and a first draft prompt. That ordering is important. If the desired outcome is undefined, a more elaborate prompt can only make the uncertainty look organized.
Before editing the prompt
Write down what a successful response must do.
Then create two or three representative inputs and check whether the revised prompt improves the behavior consistently.
A practical Claude prompting workflow
Define success
Decide which qualities matter and how you will recognize them in the answer.
Draft clearly
Write direct instructions with the essential context, constraints, and output format.
Separate inputs
Use variables, headings, or XML tags to distinguish instructions from changing content.
Add examples
Demonstrate the pattern when tone, classification, or structure is difficult to describe.
Test cases
Evaluate ordinary inputs, difficult inputs, and at least one edge case.
Refine the failure
Change the prompt in response to a specific problem instead of adding generic complexity.
Be clear about what Claude should do
Direct instructions are easier to follow than hints. If you want a recommendation, specify the decision it should support. If you want a short answer, define the limit. If certain information is unavailable, say whether Claude should ask a question, use a placeholder, or clearly mark the uncertainty. Positive instructions—what to do—are usually more actionable than a long list of prohibitions with no replacement behavior.
“Read these customer messages and tell me what people think.”
<role>
You are a customer-research analyst.
</role>
<task>
Analyze the customer messages and identify recurring needs, objections, and language customers use to describe the problem.
</task>
<constraints>
- Base every finding only on the supplied messages.
- Do not infer demographics or motivations that are not stated.
- Distinguish a recurring pattern from a single comment.
- Include a short supporting quotation for each major theme.
</constraints>
<output_format>
Return:
1. A five-sentence executive summary.
2. A table with theme, frequency, evidence, and product implication.
3. Three unanswered research questions.
</output_format>
<customer_messages>
{{CUSTOMER_MESSAGES}}
</customer_messages>Why XML tags can help
XML tags are labels such as <context>, <task>, or<source_material>. They are especially useful when a prompt contains long documents, multiple inputs, or repeated template variables. The labels make boundaries explicit and help prevent source material from blending into the instructions.
The exact tag names are less important than consistency. Use names that explain what the content represents. A short everyday request does not need XML; adding tags to “Suggest five names for a bakery” would create more ceremony than clarity.
Examples are a behavioral specification
Examples can demonstrate tone, formatting, classification boundaries, or how to handle an edge case. Anthropic’s tooling asks for example inputs and ideal outputs because they make the desired behavior testable. Good examples should be diverse enough to reveal the rule, yet close enough to the real task that Claude can apply the pattern.
- Show the exact output shape if formatting must be stable.
- Include a difficult example when the task has an ambiguous boundary.
- Keep examples consistent with the written instructions.
- Do not include private or sensitive production data in a reusable public template.
Separate fixed instructions from variables
A reusable Claude prompt normally contains fixed content and variable content. Fixed content includes the role, rules, and output contract. Variable content includes the user’s text, retrieved documents, account data, or tool results. Anthropic’s Console represents variables with double braces such as {{document}}. Keeping this separation makes prompts easier to test, reuse, and version.
Control output without micromanaging every sentence
Describe the structure and purpose of the response rather than prescribing meaningless details. “Return a decision table with recommendation, evidence, risk, and next action” is useful. “Use exactly seven bullets because seven feels complete” is arbitrary unless a real interface or process requires it. Match the prompt’s style to the output you want: a prompt filled with fragmented headings and bullets may encourage a similarly fragmented answer.
Test the prompt, not your favorite example
Create a small evaluation set before celebrating an improved response. Include typical input, sparse input, noisy input, and a case where the correct behavior is to acknowledge missing information. Evaluate the qualities you defined at the beginning—accuracy to the supplied context, format compliance, completeness, tone, or another observable criterion.
✓The prompt has one clearly stated primary objective.
✓Success criteria are visible and relevant to the real use case.
✓Instructions and source material are clearly separated.
✓Variables are labeled so the template can be reused safely.
✓Examples demonstrate the desired behavior rather than contradicting it.
✓The output format is usable without unnecessary micromanagement.
✓The revised prompt has been tried on more than one input.
When prompt engineering is not the right fix
Anthropic notes that not every failure is best solved through prompting. Cost and latency may improve more through model selection. Missing current information may require retrieval or a search tool. Repeated factual errors may require better sources or validation. A task that is not clearly defined may require product thinking before prompt writing. The prompt is one component of the system, not the entire system.
The Claude lesson
Start with success criteria, separate instructions from changing inputs, demonstrate difficult patterns, and test the behavior across real cases.