How to Prompt Engineer Claude: A Practical Guide

Prompt engineering Claude means giving it structure and explicit instructions rather than vague requests. Claude responds especially well to clear roles, XML-tagged sections, and step-by-step reasoning space — techniques that work differently than what you might use with other models. If your prompts are producing inconsistent or overly hedged answers, the fix is usually structural, not about finding a magic phrase.

This guide covers the concrete techniques that consistently improve Claude's output: how to structure prompts, how to use system prompts correctly, when to ask for reasoning, and how to test changes systematically instead of guessing.

Structure Your Prompt With XML Tags

Claude was trained to pay close attention to XML-style tags, and it uses them to separate instructions from content. This matters most when your prompt includes multiple pieces of context — a document to summarize, a question to answer, formatting rules to follow.

<document>
{{long_text}}
</document>

<instructions>
Summarize the document above in 3 bullet points.
Each bullet must be under 20 words.
Do not include any information not in the document.
</instructions>

This isn't just cosmetic. Claude uses the tag boundaries to figure out what's data versus what's instruction, which reduces cases where it treats part of your input as a command or vice versa. For anything with more than one input (a document plus a question, a schema plus examples), tag each piece separately.

Write System Prompts That Set Behavior, Not Just Persona

A common mistake is using the system prompt only to assign a persona ("You are a helpful assistant"). That does almost nothing. A useful system prompt sets constraints, tone, and boundaries that apply to every message in the conversation:

You are a support agent for a B2B SaaS billing product.
- Only answer questions about billing, invoices, and plan changes.
- If asked about something outside this scope, say so and redirect.
- Never guess at account-specific data — ask the user to provide it.
- Keep responses under 150 words unless the user asks for detail.

If you're calling Claude through an API, the system prompt goes in a dedicated field, separate from the conversation messages. Through SubToAPI, this looks the same as calling Claude directly — you send a system field alongside your messages array, documented in /docs/messages.

Tell Claude What to Do, Not Just What to Avoid

Negative instructions ("don't be verbose," "don't refuse") are weaker than positive ones because they don't tell the model what to do instead. Compare:

• Weak: "Don't give a long answer."
• Strong: "Answer in exactly 2 sentences."

• Weak: "Don't make up information."
• Strong: "If the answer isn't in the provided context, respond with 'Not found in the provided material.'"

This applies especially to formatting and refusal behavior. Claude follows explicit positive constraints much more reliably than implicit negative ones.

Give Claude Room to Reason Before Answering

For anything involving multi-step logic — math, code review, classification with edge cases — ask Claude to reason before giving a final answer, and separate the reasoning from the output:

<thinking>
Work through the problem step by step here.
</thinking>

<answer>
Give only the final answer here, no explanation.
</answer>

This two-part structure does two things: it improves accuracy on harder tasks because the model isn't forced to jump straight to a conclusion, and it lets you strip the reasoning out programmatically if you only need the final answer in production. Don't ask for step-by-step thinking on simple lookups — it just adds latency for no benefit.

Use Examples for Format-Sensitive Tasks

When you need consistent output format — JSON with specific keys, a particular tone, a fixed structure — show, don't just tell. Two or three examples usually outperform a paragraph of formatting rules:

Convert each request into this format:
{"intent": "...", "urgency": "low|medium|high"}

Example:
Input: "My payment failed three times, I need this fixed today"
Output: {"intent": "payment_failure", "urgency": "high"}

Now convert:
Input: {{user_request}}

This matters even more once you introduce tool calling — Claude needs a precise sense of when to invoke a tool versus respond directly, and examples of both cases in the prompt reduce misfires. See /docs/tools for how tool definitions and prompts interact in a live API call.

Test Changes Against Real Traffic, Not One-Off Examples

Prompt engineering isn't a one-time task — it's iterative, and the failure mode most teams hit is tuning a prompt against three examples that happen to work, then shipping it against traffic that breaks it. Keep a small set of representative inputs (including edge cases and ambiguous ones) and re-run them every time you change the prompt.

If you're building this into an application, it helps to separate prompt iteration from infrastructure work. SubToAPI turns your existing Claude access into a standard HTTPS API with sub_live_ keys, so you can test prompt versions with plain curl requests or from your app's backend without managing separate credentials per environment. Streaming, usage metadata per key, and team seats are documented in /docs, with a quickstart at /docs/quickstart.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "system": "Answer only in valid JSON.",
    "messages": [{"role": "user", "content": "Extract name and date from: John, March 3rd"}]
  }'

Common Mistakes to Avoid

• Burying instructions mid-document. Put instructions at the start or end of the prompt, clearly tagged — not sandwiched inside a long context block.
• Vague success criteria. "Make it good" gives Claude nothing to optimize toward. Define length, tone, format, and what to exclude.
• Overloading one prompt with too many tasks. If a prompt is doing five things, split it into a pipeline of smaller, single-purpose calls.
• Ignoring context length. Long, unstructured context degrades instruction-following even within a large context window — trim and tag rather than dumping everything in.

FAQs

Does prompt engineering for Claude differ from other LLMs? Yes, meaningfully. Claude responds strongly to XML-tagged structure and to system prompts that set explicit behavioral rules, and it follows positive instructions ("do X") more reliably than negative ones ("don't do Y"). Techniques tuned for other models often need restructuring to get the same results from Claude.

Should I always ask Claude to show its reasoning? No. Reasoning steps help on multi-step or ambiguous tasks but add latency and cost on simple ones. Use a <thinking> block for logic-heavy tasks and skip it for straightforward lookups or classifications.

How do I test prompt changes reliably? Keep a fixed set of representative test inputs, including edge cases, and re-run them against every prompt revision rather than eyeballing one or two examples. If you're calling Claude via an API like SubToAPI, scripting this with curl or a small test harness makes it repeatable — see /docs/quickstart to get started.