Prompt engineering

What you’ll be able to do

Write instructions that are specific and positively framed
Place each instruction where its scope is unambiguous
Upgrade to few-shot only when instructions genuinely fail
Sanitize untrusted input before it reaches the prompt

What you need to know

Specific and positively framed

The named principle is instruction clarity: say what to do, not a list of things to avoid. A stack of negatives gives the model nothing concrete to aim at, and each one has to be held in mind while generating.

before — three negatives, no target

"Summarize the visit. Don't be too long, don't leave anything important out, and avoid being vague."

after — one explicit target

"Summarize the visit as a SOAP note using exactly these four headers: Subjective, Objective, Assessment, Plan. Omit any section with no relevant content rather than writing 'N/A.' Keep each section under 80 words."

Notice the second version is longer and that's fine. Clarity is the goal, not brevity — the cost of a few extra instruction tokens is trivial next to a reroll.

Placement decides scope

Where an instruction lives tells the model when it applies. Get this wrong and a correct instruction still fails.

System prompt — durable behaviour that holds every turn: role, tone, standing constraints, output conventions.
User message — task-specific direction for this request only.
Tool description — constraints that apply only when that tool is in play.

ScenarioA discount rule applies only to orders over $500. It's written into the middle of a 2,000-token system prompt alongside forty other rules.

The instruction is correct and still unreliable, because it's competing with everything else for attention on every single turn — including the majority of turns where no order is involved at all. Move it to the description of the tool that handles orders, where its scope is self-evident and it only competes when relevant.

The few-shot upgrade, and when to take it

Few-shot examples are the standard next move when instructions alone don't generalise to edge cases. They're cheaper than fine-tuning and faster than rewording by trial and error.

But they bill on every request, permanently. Reach for them when a clearer instruction has actually been tried and the model still drifts on unusual inputs — not as a reflex. The exam offers few-shot as a distractor in questions where the real problem is elsewhere (weak tool descriptions, an unpinned model), so check the diagnosis before accepting the remedy.

Input sanitization

Untrusted text — a user field, a scraped page, an uploaded document — gets cleaned and delimited before it reaches the prompt, not after the model has already read it. Strip or escape control sequences, enforce length limits, and wrap it in explicit tags so its boundary is unambiguous.

This is the prompt-engineering side of the content boundary from lesson 2.5. It's a hygiene layer, not a security guarantee — Domain 7 covers what actually stops an action from executing.

The blueprint names refinement as a practice, which implies measurement: change one thing, run your evaluation set, compare. Changing four things and eyeballing three outputs isn't refinement, it's guessing with extra steps.

Key concept

Say what to do rather than what to avoid, and put each instruction where its scope is obvious — durable behaviour in the system prompt, tool-specific constraints in the tool description. Few-shot is an upgrade you earn, not a default.

Practice scenario

ScenarioAn instruction reads: "don't ramble, don't skip anything important, don't be vague." Output quality is inconsistent.

Work it through, then open this

Three prohibitions and no target. Replace with one positively framed instruction carrying an explicit format and limit — headers to use, sections to omit rather than mark N/A, a word ceiling. Then check whether the rule is even system-prompt material, or whether it belongs on the tool that produces the output.

Build exercise — Rewrite one instruction and measure it

Beginner · 25 min

What you’ll learn

Converting stacked negatives into one specific target
Placing an instruction where its scope is unambiguous

Find an instruction in your system prompt written as a list of things to avoid. Rewrite it as one specific, positively framed instruction with an explicit format.
- Why: Negatives give the model nothing to aim at and all have to be held in mind at once.
- You should see: A single sentence the model could be graded against.
Scan the rest of that system prompt for any rule that only applies when a particular tool runs, and move it into that tool’s description.
- Why: A conditional rule in a general system prompt competes for attention on every turn, including the majority where it’s irrelevant.
- You should see: A shorter system prompt and a more specific tool description.
Run both versions against the same ten inputs and compare.
- Why: Refinement without measurement is guessing with extra steps.
- You should see: A difference you can point at — or evidence the original was fine, which is also worth knowing.

Exam traps

Stacking negative instructions

A list of things to avoid gives the model no target. One specific positive instruction outperforms four prohibitions.

Burying conditional rules in a long system prompt

A rule that applies to one tool competes with everything else on every turn. Scope it to the tool description.

Adding few-shot examples before diagnosing the real cause

They bill forever and often paper over a different problem — weak tool descriptions or an unpinned model version.

Sanitizing untrusted input after the model has read it

The boundary has to be drawn before the content enters the prompt, not applied to the output afterwards.

Sources

Claude Developer Platform Docs

What you'll be able to do