Reference · Anthropic Claude

Claude — prompt engineering

Techniques that move output quality: specificity, XML structure, few-shot, chain-of-thought, system prompts and output control.

ClaudePrompting
01

Prompt engineering, no filler

The techniques that actually move output quality — structure, context, examples and control. Built to scan.

01 — FOUNDATION

Be specific and direct

Assumptions fill the gaps. Close the gaps yourself.

  • State what, for whom and in which format — not just the topic.
  • Positive instruction beats negative: write "answer in prose" rather than "no bullets".
  • Give context on why — the purpose drives tone and depth.
  • Set explicit limits: length, reading level, what may be left out.
# weak
Write about zero trust.

# strong
Write a 200-word paragraph on zero trust for a
non-technical management team. Focus: why the
perimeter model fails. Prose, no jargon.
02 — STRUCTURE

XML tags to separate

Claude is trained to respect tags. Use them to split instruction from data.

  • Wrap input, examples and rules in named tags.
  • Refer to tags later in the prompt by name.
  • Consistent tag names make long prompts robust.
<instruction>
Summarise the report in 3 bullet points.
</instruction>

<report>
{{paste text}}
</report>

<format>
Each bullet max 15 words.
</format>
03 — EXAMPLES

Few-shot & multishot

The fastest route to consistent format and tone.

  • 2–5 examples cover most edge cases.
  • Show both input and desired output — not just the output.
  • Include a hard or atypical example, not only the easy one.
  • Keep examples consistent in style — deviations get copied.
classification extraction tone-matching formatting
04 — REASONING

Chain of thought

Let the model think before it concludes on complex tasks.

  • Ask explicitly to "think step by step" for analysis, maths, logic.
  • Structure thinking in a <thinking> tag, answer in an <answer> tag.
  • Do not use it for simple lookups — it costs tokens with no gain.
  • Want to hide the reasoning from the end user? Ask for it separately.
Think the problem through in <thinking>.
Give only the final recommendation in <answer>.
05 — ROLE

System prompt & persona

Set the role in the system prompt — it hits expertise and tone in one move.

  • System prompt = who Claude is; user turn = the task.
  • A concrete role beats a vague one: "DFIR analyst reviewing an IR report".
  • Put durable rules (tone, language, output) in the system, not in every message.
// system
You are an experienced governance consultant.
Answer concisely, in English, and always with
concrete actions rather than general advice.
06 — CONTROL

Steer output directly

Prefill and format control remove leading filler.

  • Prefill the assistant reply with e.g. { to force clean JSON.
  • Prefill with a tag to skip the preamble.
  • Ask for an exact schema when output is parsed by machine.
  • "Answer only with …" when you want to avoid helpful chatter around it.
# force JSON, no chatter
Answer ONLY with valid JSON in this schema:
{ "risk": "high|medium|low",
  "rationale": "string" }
07 — LONG DOCUMENTS

When the context is large

Order and placement matter when you feed whole reports in.

Data firstPut long documents at the top of the prompt, the instruction last. It improves quality markedly on large inputs.
Tag your sourcesWrap each document in <doc> with source/title, so answers can cite precisely.
Ask for quotesAsk Claude to find relevant quotes before the analysis — it grounds the answer in the text.
Split big tasksChain prompts: extract → analyse → summarise. Each step is more precise than one mega-prompt.
08 — AVOID

Common mistakes

Polite vagueness"Could you maybe take a look at …" — be direct about the task; precision does not confuse the model.
Negative stackingA list of "don'ts" is weaker than one clear description of what you want.
Everything in one messageConflicting requirements in the same prompt. Split into steps or separate with tags.
CoT on everythingStep-by-step on trivial tasks wastes tokens and latency with no gain.
Iterate. Prompt engineering is empirical. Write a draft, run it on real (including hard) cases, and fix one thing at a time. Keep what works.