Best Practices for Prompt Engineering Claude

Prompt engineering for Claude comes down to a small set of repeatable techniques: give clear structure, separate instructions from data, show examples instead of describing them, and test changes systematically rather than tweaking blindly. Claude responds especially well to explicit formatting (XML tags, numbered steps) and to being told what role it should play before being given a task.

This article covers the specific practices that consistently improve output quality — not generic "be clear and specific" advice, but concrete patterns you can copy into your own prompts today, whether you're calling the API directly or through a gateway like SubToAPI.

Start With a Strong System Prompt

The system prompt sets the frame for everything that follows. Claude uses it to establish role, tone, constraints, and output format — and it's more effective than cramming the same instructions into the user message.

A good system prompt typically includes:

• Role: who Claude is acting as ("You are a senior backend engineer reviewing pull requests")
• Constraints: what it should not do ("Never suggest removing error handling")
• Output format: how the response should be structured ("Respond only with a JSON object matching this schema")

{
  "model": "claude-sonnet-4-5",
  "system": "You are a technical writer. Respond only in markdown. Never use emojis. Keep responses under 300 words.",
  "messages": [
    { "role": "user", "content": "Explain what a connection pool is." }
  ]
}

Keeping format and tone rules in the system prompt — rather than repeating them in every user message — also reduces token usage across a long conversation.

Use XML Tags to Separate Instructions From Data

Claude was trained extensively with XML-style tags, and it's noticeably better at following instructions when the prompt is structured with them. This matters most when you're passing in documents, code, or user-generated content alongside instructions — mixing the two in plain text increases the chance Claude treats data as an instruction.

<document>
{{long_contract_text}}
</document>

<instructions>
Summarize the document above in 3 bullet points.
Only reference clauses that appear in the document.
</instructions>

This pattern also makes prompts easier to template programmatically, since you can swap {{document}} content without touching the instruction block.

Show Examples Instead of Describing Behavior

Few-shot examples outperform lengthy descriptions almost every time. If you want a specific output style, structure, or tone, show 2–3 examples of input/output pairs rather than trying to explain the rule in prose.

Convert the following support tickets into a one-line summary.

Example:
Input: "The app crashes every time I open the settings page on iOS."
Output: iOS settings crash

Now convert this ticket:
Input: "{{ticket_text}}"
Output:

This is particularly useful for classification, extraction, and formatting tasks where "correct" is easier to demonstrate than to define.

Let Claude Think Before It Answers

For tasks involving reasoning, math, or multi-step logic, asking Claude to work through the problem before giving a final answer measurably improves accuracy. You can scope this with tags so the reasoning doesn't leak into the final output your application consumes:

Think through this step by step inside <thinking> tags, then give your
final answer inside <answer> tags. Only the content in <answer> will be
shown to the user.

Your application code can then parse out only the <answer> block, keeping the reasoning hidden from end users while still benefiting from it.

Be Explicit About Output Format

If you need structured output — JSON, a specific markdown layout, a fixed set of fields — say so explicitly and give an example of the exact shape you want. Claude will generally follow a schema closely if you show it one, but vague instructions like "return the data as JSON" without an example lead to inconsistent key names and nesting.

Return your answer as JSON with exactly these fields:
{
  "title": string,
  "summary": string,
  "tags": string[]
}
Do not include any text outside the JSON object.

If your workflow needs structured function calls rather than free-form JSON, tool use is a more reliable mechanism — see the tool use docs for how this works end to end.

Iterate With a Fixed Test Set

Prompt engineering is empirical. Instead of editing a prompt and eyeballing one response, keep a small set of representative inputs (5–10 is usually enough to start) and re-run them every time you change the prompt. Track regressions as carefully as improvements — a tweak that fixes one case can break another.

This matters more once a prompt is in production. Small wording changes can shift output length, tone, or format in ways that affect downstream parsing, so testing against real examples before shipping a prompt change is worth the few minutes it takes.

Where SubToAPI Fits In

None of this changes based on how you call the model, but your workflow does. If you're prototyping prompts across a team, SubToAPI turns your existing Claude access into an HTTPS API with its own sub_live_... keys, so different team members or environments (staging, testing, production) can use separate keys without sharing credentials. Usage metadata per key makes it easier to see which prompt versions are consuming more tokens, and streaming support means you can test "thinking before answering" patterns interactively rather than waiting for full completions. Check the quickstart to get a key running in a few minutes, or look at the messages docs for the exact request format.

Summary

The highest-leverage prompt engineering practices for Claude are: put role and format rules in the system prompt, separate instructions from data with XML tags, show examples instead of describing behavior, let Claude reason before answering on harder tasks, and test changes against a fixed set of inputs instead of ad hoc spot-checks. These aren't Claude-specific tricks — they're consistent with how the model was trained to parse structure and follow demonstrated patterns.

Questions

Does prompt structure actually change Claude's output quality, or is this overstated? It's not overstated. Structured prompts (system prompt + XML tags + examples) produce more consistent formatting and fewer instruction-following errors than unstructured prose, especially on longer or multi-part tasks.

Should I put instructions in the system prompt or the user message? Stable rules that apply to every request (role, tone, output format) belong in the system prompt. Task-specific content and data belong in the user message, ideally wrapped in XML tags to keep them separate.

How many examples do I need for few-shot prompting to work? Two to three well-chosen examples is usually enough to establish a pattern. More examples help with edge cases, but diminishing returns set in quickly — quality of examples matters more than quantity.