Prompt engineering for Claude: clarity, examples, placement and format

1.Explicit instructions that carry their reason

Prompt engineering is the work of writing and adjusting the text you send Claude until its output meets your criteria. The first thing to fix is usually vagueness. Claude does not guess at ambitions you left out. "Create an analytics dashboard" gets you a reasonable dashboard. "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation" gets you the thorough one you actually wanted. If you want depth, specific features or a particular quality bar, put it in the prompt.

Specific means stating constraints, audience, structure and limits. Compare "Create a meal plan for a Mediterranean diet" with a request that names the condition (pre-diabetic management), the budget (1,800 calories daily), the meals to cover and the breakdown to include. When order or completeness matters, as with a review checklist or a migration procedure, write the instructions as a numbered list so no step gets merged or skipped.

Giving the reason behind a rule makes Claude follow it more reliably than repeating it louder. "NEVER use ellipses" is a bare command, and a voice assistant that runs on it will still produce the occasional "...". "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them" works better. Claude now knows the actual goal, so it can also avoid related problems the rule never mentioned, such as other symbols a speech engine would stumble on. The same applies to formatting: a prompt that says what to do ("write in smoothly flowing prose paragraphs") beats one that only says what to avoid ("do not use markdown").

The first version of a prompt is a draft. It rarely works perfectly, so run it, read where the output falls short, and revise; that loop is iterative refinement. It applies to the output as well as the prompt: a response can become the input to a follow-up prompt that asks Claude to verify or expand its own earlier statements, which catches inconsistencies a single pass leaves in. A summary workflow shows the shape. The first prompt writes the summary, the second reviews it for accuracy, clarity and completeness, and the third improves it using that feedback. Each pass has one job, at the price of an extra call and its latency.

Sources123

2.Zero-, one- and few-shot examples

An example shows Claude what you want instead of describing it. It is one of the most reliable ways to steer format, tone and structure. A prompt with no examples is zero-shot, one with a single example is one-shot, and one with several is few-shot (also called multishot). Zero-shot is fine when a clear instruction already gets the output you need. Examples earn their place when the format is easier to show than to describe, when you need a particular tone, when the task follows subtle conventions, or when plain instructions have not produced consistent results.

Start with one example and add more only when the output still misses. A one-shot summarisation prompt might show a single article with its three-sentence summary and then say "Now summarize this article in the same style". If summaries of long technical papers still drift, add a second example of exactly that kind. Adding examples one at a time like this tells you which example fixed what.

Claude pays very close attention to the details of examples, so it copies their accidents along with their intent. Three examples that all start with "Great question!" or all run to exactly two sentences teach that pattern too. Good examples have three properties:

- Relevant: they mirror your real inputs, not a toy version of them. - Diverse: they cover edge cases and vary enough that no unintended pattern appears. - Structured: each sits in <example> tags, with the set inside <examples>, so Claude can tell example from instruction.

Sources12

3.What goes in the system prompt, the user turn and tool results

A prompt has several parts, and each kind of content belongs in a particular one. The top-level system field holds what should apply from the very first turn: the role Claude plays and the standing rules. The user turn holds the task itself, with its documents and the question. Setting a role in the system prompt is the smallest change that steadies behaviour and tone. If a code-review assistant swings between chatty and terse, one sentence fixes most of it.

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system="You are a helpful coding assistant specializing in Python.",
    messages=[
        {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ],
)

Agents have two more places for content. Third-party content belongs in tool_result blocks. Your own instructions do not: Claude treats tool-result content as untrusted data and may ignore or flag directions placed there. Put them in a user turn after the tool_result instead. On supported models a mid-conversation system message also works. It has the same authority as the top-level system field, and it suits instructions that only matter later in the conversation.

For long inputs (20k+ tokens), put the documents first and the query last. That order improves performance across all models. Wrap each document in <document index="n"> inside a <documents> parent, with the text in <document_content> and its origin in a <source> subtag such as annual_report_2023.pdf. This is the fix when Claude says a fact came from the wrong file: two reports pasted as one undifferentiated block give it no boundary to attribute against. Then ask for grounding. Have Claude first pull the relevant quotes into <quotes> tags and only then do the task from those quotes. This keeps it on the parts of a long document that matter.

Sources145

4.Prompting for a consistent output format

When downstream code parses the output, define the format exactly. Prompting for a format makes it far more consistent but does not guarantee it; schema enforcement is a separate API feature, covered in [Output handling](lesson:6.3). There are three prompt-level tools. The first is a stated format, such as "output in JSON format with keys: sentiment, key_issues, action_items". The second is a filled-in template showing every element you expect. The third is an XML tag Claude must write its answer inside, which your code then extracts.

<competitor>
  <name>Rival Inc</name>
  <overview>A 50-word summary.</overview>
  <swot>
    <strengths>- Bullet points</strengths>
    <weaknesses>- Bullet points</weaknesses>
    <opportunities>- Bullet points</opportunities>
    <threats>- Bullet points</threats>
  </swot>
  <strategy>A 30-word strategic response.</strategy>
</competitor>

Prefill starts Claude's answer for it. You put a partial assistant message last in the messages list, and Claude continues from it. Prefilling { skips the "Here's the JSON you requested:" preamble. Prefilling The answer is ( with max_tokens set to 1 returns a single multiple-choice letter.

message = anthropic.Anthropic().messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1,
    messages=[
        {
            "role": "user",
            "content": "What is latin for Ant? (A) Apoidea, (B) Rhopalocera, (C) Formicidae",
        },
        {"role": " ? ", "content": "The answer is ("},
    ],
)

Prefill on the last assistant turn does not work on newer models: it is no longer supported starting with Claude 4.6 models and Claude Mythos Preview. On those models, put the same guidance in the instruction instead: "Output only valid JSON with no preamble. Begin your response with an opening brace." The style of the prompt itself also counts. A prompt full of markdown pulls the response toward markdown, so if you want plain prose, write the prompt in plain prose.

Sources6512

5.Wrapping and labelling untrusted input

Any text you did not write is a possible source of instructions you did not intend. Claude might read an email body, a fetched web page or a user's free-text field. Users who attack directly and third-party content that attacks indirectly are separate threat models, covered in [Prompt injection and jailbreaks (two threat models)](lesson:7.1). The prompt-engineering job is narrower: lay out the prompt so Claude can always tell your instructions apart from the data it is processing.

Start by wrapping untrusted text in a tag that names it, such as <content> around a user submission or <tool_output> around what a tool returned. Then say what the content is and where it came from, for example "the body of an inbound email from an unknown sender". A system prompt policy completes the setup: retrieved content is data, and instructions inside it are information to report, not commands to follow. Before any of this, input validation can filter user text for known injection patterns.

Tags separate content, but they do not seal it. An attacker who knows your tag name can type </content> and write text that looks like it sits outside the wrapper. Where possible, JSON-encode third-party strings instead. Escaping makes the boundary unambiguous, so the payload cannot close a quote or tag to break out. A field like "body": "Ignore previous instructions..." stays plainly a value.

Sources4

6.Refining a prompt against failing cases

Before refining a prompt, you need success criteria and a way to test against them. Building those is covered in [Eval-driven iteration](lesson:2.2). This section is about how to change the prompt once an eval fails: one change at a time, re-running the failing cases after each, so every gain or regression can be traced to a single edit. If you add a role, three examples and a format template together and the score moves, you cannot tell which change did it, or which one broke the cases that used to pass.

The failing cases usually suggest the change. Take a ticket classifier that handles clear tickets but misses a cluster of ambiguous ones. If the team has saved those inputs with their ideal outputs, the next step is to turn them into diverse, tagged few-shot examples. Plain instructions are not producing consistent results, and that is exactly when examples help. Add them, re-run, and add more only if cases still fail.

Adjustment can mean removing text as well as adding it. A prompt written for an older model may tell it to be more thorough or to use tools more aggressively, and newer models can overdo that, so dial such guidance back when you migrate. Some failures are not prompt problems at all. If latency or cost is what fails, choosing a different model may fix it more easily than any rewrite.

Sources7812

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Writing a rule in capitals, or repeating it, is the most reliable way to make Claude obey it.Why is that wrong?

   Giving the reason behind the rule works better: Claude understands the goal and extends it to related cases the rule did not name.

   Covered in Explicit instructions that carry their reason

2. 2.With long documents, put the question first so Claude knows what to look for while reading.Why is that wrong?

   Long documents go near the top of the prompt, with the query, instructions and examples below them.

   Covered in What goes in the system prompt, the user turn and tool results

3. 3.Prefilling the last assistant turn works on every Claude model.Why is that wrong?

   Newer models reject a prefilled last assistant turn, so on those models the format guidance has to go in the instruction itself.

   Covered in Prompting for a consistent output format

4. 4.More examples are always better, so start with as many as you can write.Why is that wrong?

   Start with one example and add more only if the output still misses, because Claude also picks up any accidental pattern the examples share.

   Covered in Zero-, one- and few-shot examples