Chapter 1. Instruction design

Learning objectives

• Rewrite vague work requests into verifiable instructions with explicit goals, constraints and success criteria.
• Set the permitted scope of invention and required evidence according to task type: extraction, transformation, generation or judgment.
• Turn negative instructions into positive instructions with a short reason.
• Explain the roles and priority of system (developer), user and assistant messages, and place rules and inputs appropriately.
• Find instructions that conflict and resolve them using applicability conditions and priorities.
• Write a policy distinguishing when to ask, when to state an assumption, and when to withhold a decision if information is missing.

Introduction

A publisher’s marketing team began using a model to write copy introducing new books. The team lead’s first instruction was “Write an attractive introduction to the new book, not too long.” The first day’s result looked convincing. But when five team members used the same instruction over a week, the results varied widely. Some introductions were two lines long, others ten, and some boasted awards the book had never won. The editor reviewing them had to apply different criteria to every piece. Soon, people were saying that using the model was more trouble than it was worth. Someone in a meeting said the model was behaving strangely that day. In fact, it had followed the instruction faithfully each time. With no definition of “attractive” or “not too long,” it simply filled in whichever criteria seemed most plausible at the time.

This chapter explains how to fill those gaps. Starting with what kind of colleague the model resembles, it covers task types and the four elements of good instructions, how to turn unverifiable expressions into verifiable conditions, how to state the desired action and its reason instead of only a prohibition, message roles, a template separating rules from data, conflict resolution, and policies for missing information. The deeper discussion covers the right level of detail, editing instructions down, and where secrets belong.

Key concepts

The model is a capable colleague on their first day

However brilliant a new colleague is, they do not know your team’s conventions, customers or report formats. If you only say “Please tidy up this report,” they will tidy it up in whatever way seems most plausible to them. Anthropic’s guide recommends thinking of the model as a highly capable new employee without context about your norms and workflows. Its simple golden-rule test is to show a colleague with little context the prompt and ask whether they could follow it as written. If your colleague would be confused, the model will be too.

The analogy has limits. A new human employee can ask the person next to them, remember last week’s meeting and feel responsible for mistakes. A model cannot know circumstances outside the context it receives, and often fills gaps without asking, even if no instruction forbids questions. When a result is wrong, distinguish two causes.

Identify the task type first

Deciding what kind of task you are doing before writing instructions resolves many later choices. The permitted scope of invention and the evidence required vary by task type.

Mix generation instructions such as “polish it for readability” into extraction, and wording absent from the source may appear. Ask for a judgment without a criteria table, and the model will invent plausible criteria. If a prompt mixes task types, identify the type of each step or separate the steps as Chapter 4 explains.

Four elements of a good instruction

Good instructions answer four questions.

Removing one element at a time shows why all four are needed.

Success criteria are the element most often missing. Words like “concise,” “an appropriate length” and “high quality” cannot be checked. Change them into conditions you can verify from the result, such as “five lines or fewer,” “conclusion in the first sentence” or “one piece of evidence per item.” This makes human review easier and leads directly into the automated evaluation covered in Chapter 5. Anthropic’s prompt engineering overview also says to establish three things before refining a prompt: success criteria, a way to test against those criteria, and a first draft.

A role sets a perspective; it does not supply knowledge

A one-sentence role in the system prompt focuses the model’s perspective and tone on the task. Anthropic’s documentation explains that even a single sentence can make a difference. Still, distinguish what a role statement can and cannot do.

“Answer like a tax expert with 20 years of experience” does not teach the model your company’s tax procedures. Supply the required criteria in the context, and state what the model may decide and when it must hand the matter to a person. A role is a starting point; it cannot replace the other three elements.

Turn vague requirements into verifiable instructions

Workplace requests usually arrive as adjectives: “clean,” “persuasive,” “customer-friendly.” The following process helps translate them into instructions without omissions.

1. Mark every adjective. Underline adjectives and adverbs in the request that have no judgment criteria.
2. Ask the requester what would make them describe it that way. Only they know whether “clean” means one topic per paragraph or the presence of a table.
3. Convert it into observable signals. Specify numbers (characters, items), positions (first sentence, last line), formats (tables, bullets), or presence of required information (price, deadline, contact).
4. State failure conditions too. Define immediate failures, such as “Fail if there is even one unsupported numerical claim.”
5. Pilot-test the criteria. Apply the new criteria to a few previous outputs and make any criteria that produce disagreement more specific.

Request: Make a new-member welcome email friendly and not too long.

Verifiable instructions:
- The reader is an individual who has just joined. Use polite declarative sentences and no more than one exclamation.
- Keep the body within 600 characters and use three paragraphs.
- In the first paragraph, state one action the member can take immediately.
- Mention only benefits in the supplied benefits list. Any benefit absent from the list is a failure.

These revised instructions give reviewers a standard and provide a basis for recording what changed when that standard changes.

Say what to do rather than only what not to do

“Do not use tables” only states a prohibition and leaves open what to use instead. Anthropic’s guide recommends saying what you want rather than what you do not want: for example, “Write in smoothly connected paragraphs” instead of “Do not use Markdown.”

Weaker instruction: Do not use bullet points.
Better instruction: The response appears in one panel on a kiosk screen, so write one paragraph of two or three declarative sentences.

The prompt’s own formatting also affects output. Anthropic’s documentation explains that prompt formatting can influence response formatting, and removing Markdown from a prompt can reduce Markdown in the output. A prompt full of headings and bullet points encourages an answer full of headings and bullet points.

Positive instructions do not always replace prohibitions. Hard boundaries, such as exposing personal information or making unconfirmed promises, are clearer when explicitly prohibited. Even then, add what to do instead. “Do not promise an unconfirmed date. If asked about scheduling, explain when the date will be confirmed and how to check it.” The model now has an action to take in place of the prohibited one.

A reason helps the model generalize

Adding a reason makes an instruction more effective. Anthropic’s example contrasts simply forbidding ellipses with explaining that a text-to-speech engine will read the response and cannot pronounce them. The guide notes that the model can generalize from an explanation. Knowing the reason helps it apply the same principle in similar situations. Still, explicitly list symbols that must be avoided and check the output.

One or two sentences of explanation are enough. Long background explanations can obscure the main instruction. A good reason identifies who would have difficulty, where, and why. For example: “Write dates in the format 2026-10-20 because the settlement system reads the result directly.”

Number procedures when order matters

Combining several steps in one paragraph with commas makes omissions and reordering more likely. Anthropic’s guide recommends numbered or bulleted sequential steps when order or completeness matters. Numbering also lets reviewers check which steps were followed.

Follow this sequence before answering.
1. Find the order number in the inquiry. If it is missing, ask for it first and stop.
2. Check payment status in the order information and select the response script for that status.
3. End the guidance with the next contact time.

Conversely, numbering items whose order does not matter can harm a natural answer by making the model follow an unnecessary sequence. Use numbers where order or omission changes the result.

Message roles and priority

When you use a model through an API, where you place an instruction matters as much as its content. Using a workplace analogy, the system (developer) message is company policy, the user message is the customer request, and the assistant message is what the employee has already said.

OpenAI’s guide compares a developer message to a function definition and a user message to the arguments passed to it. It gives an example developer-message structure in the order Identity, Instructions, Examples and Context, with context toward the end. Google’s Gemini guide likewise recommends placing core behavioral constraints, role (persona) and output format requirements in the system instruction or at the start of the user prompt.

Avoid two misconceptions. First, writing “System instruction:” in a user message does not give that sentence system authority. Authority comes from the message’s position, not its introductory words. Second, mixing shared rules into a user message blurs priority and the boundary against prompt injection, where a user writes “ignore the previous rules.”

A template separating rules from data

When a team starts reusing a prompt, copies proliferate with fixed and changing parts mixed together. Once someone edits a rule in one copy, nobody knows which copy is current. The solution is to separate rules from data.

[Fixed rules: version 3.2, changed 2026-10-14]
You draft English emails to overseas business partners.
- Use only the amounts and delivery dates inside <order>.
- Mark unconfirmed items [Confirmation needed].

[Variables: change with each request]
<order>{{ORDER_SUMMARY}}</order>
<buyer_message>{{BUYER_MESSAGE}}</buyer_message>

Double braces ({{...}}) conventionally mark placeholders populated with values for each request. Maintain fixed rules in one place, define each variable’s name and expected contents, and record what changed, why, and which evaluation results informed the change. Chapter 5’s regression evaluation complements this record.

The author resolves conflicting instructions

Prompts edited by many people tend to accumulate clashing instructions such as “always one line” and “provide all evidence.” The model picks one side on each request, producing inconsistent output. The author must find the conflict and merge the instructions into one rule, rather than handing the decision back to the model with “strike a balance.”

Distinguish two kinds of conflict.

Resolve business-condition conflicts as follows.

1. List every condition. Put each instruction condition on its own row in a table.
2. Separate requirements from preferences. Mark conditions whose violation causes harm as required, and desirable conditions as preferred.
3. Find incompatible pairs. Identify combinations that cannot both be met for one input.
4. Separate conditions of application. See whether they can become “A by default, B in this case.”
5. If they cannot be separated, state priority. “If they conflict, meet the required condition and add one line explaining why the preferred condition was not met.”

Before: Always use a table. / Keep it short enough for a messenger preview.
After: Use no more than three sentences by default. Use a table only when comparing three or more items,
       and precede the table with a one-sentence conclusion.

A policy for missing information

When required information is absent, the model has three options: ask, proceed with an assumption, or withhold judgment. Without a policy, it usually fills in a plausible value and continues. Set the policy according to the information’s nature.

Permission to say “I do not know” is part of the policy. Anthropic’s hallucination-reduction documentation describes explicitly allowing uncertainty as a simple way to substantially reduce false information. Permission alone is insufficient, though. Define the next action too, such as “Explain that the relevant department must confirm this and provide its contact details,” so the model knows to stop at a gap.

Acting versus suggesting, and the trap of emphasis

For a model with tools, “suggest improvements” and “make improvements” are very different instructions. Anthropic’s guide says newer models are trained to follow instructions precisely. Asked “Could you suggest improvements?”, they may only suggest, even if you intended changes. If you want a change, direct the action: “Fix this function.” Conversely, if acting without asking is the problem, place a default policy in the system prompt: provide information and recommendations when intent is ambiguous, and execute only on an explicit request.

Actions that are difficult to reverse need separate rules. Require confirmation before tasks such as deleting files, sending external messages or making payments, which are hard to undo or visible to others. List examples of tasks requiring confirmation.

Review emphasis too. Aggressive instructions written for earlier models, such as “CRITICAL: You MUST use this tool!”, can cause overreaction in newer ones. Anthropic’s documentation recommends ordinary wording such as “Use this tool in these cases,” because language added to counter underuse can now cause excessive calls. Emphasis cannot replace conditions. When changing models, first find and remove emphasis and phrases such as “be exhaustive” that compensated for the old model’s weaknesses. Explicitly request the desired scope, such as “Include as many features as possible,” and compare before and after on Chapter 5’s evaluation set. Anthropic also advises validating techniques measured on one model with your own evaluation before applying them to another.

Going deeper

Keep the right altitude and start with a minimal prompt

Anthropic’s context engineering article identifies two system-prompt failures. One hardcodes every exception as an if-else rule, making the prompt brittle and difficult to maintain. The other gives vague, high-level guidance without concrete signals or assumes shared context. The “right altitude” between them provides a framework for judgment through principles, reasons and a few representative cases.

The article also gives a practical method: start with a minimal prompt on the best available model, then add instructions and examples based on observed failures. Accumulating rules for imagined exceptions leads to conflicts and makes it impossible to tell which rules help. A safer sequence is to run real input samples through the minimal prompt, group failures by type, and add one principle and one representative example for each type.

Edit instructions down and keep secrets in the right place

Instructions tend to grow with revisions because each failure adds another line. Periodically make these edits.

• Merge sentences that mean the same thing.
• Replace vague references such as “it” and “the above” with actual names.
• Replace capitals, exclamation marks and emphasis such as “never” with conditions.
• After deleting a sentence, compare results on the evaluation set to see whether it was doing useful work.

Some information should never enter instructions: for example, payment keys or internal discount-approval criteria whose exposure would cause harm. Anthropic’s prompt-leak documentation starts from the premise that no method is perfect and advises omitting proprietary information unnecessary for the task. Elaborate anti-leak instructions can reduce task performance, so use them only when needed and try monitoring methods such as output filtering first. Credentials such as payment keys must always stay in server-side tools, outside prompts. Give the model only the minimum permissions needed. Chapter 3 returns to this least-privilege principle in its discussion of prompt injection.

At work

Maru Cultural Foundation: one request, three channels

Kwon, a communications coordinator at the fictional local Maru Cultural Foundation, needs to announce an autumn outdoor performance by text message, website notice and banner. The planning team sends one line: “Short and friendly, but leave out none of the conditions.” Entering it unchanged produces a twelve-line text message and banner copy that even includes the rainy-weather venue-change condition.

Kwon first turns the request into a task specification. This is transformation: the planning team’s performance brief is the source, and only wording should change by channel while meaning is preserved. Kwon then asks what “leave out none” means. The answer is five items: date and time, venue, whether admission is free, rainy-weather changes and contact details. “Short” means something different for each channel.

The table exposes a conflict: text messages and banners cannot include all five items. Kwon keeps completeness as a requirement but separates its conditions of application. The website notice must contain all five; text messages and banners are explicitly defined as entry points leading to that notice. The text message therefore requires a details link.

Kwon rejects two alternatives. One is requesting all three channels at once with “adapt appropriately to each channel.” This leaves judgment to the model and would produce the same variation. The other is repeating “never write at length” in bold. Emphasis changes nothing without a definition of “long.”

The final instructions contain shared rules (tone and facts limited to the brief), required information and length per channel, and a one-line reason for each. For text messages: “Recipients see only the first line in the notification preview, so place date, time and venue in the first line.” Testing five past event briefs produces matching pass/fail judgments from two reviewers using only the table. Kwon has changed the definitions of “short” and “complete,” rather than the elegance of the prose.

Hanul Textiles: turning an overseas-buyer email assistant into a team tool

The sales team at fictional fabric exporter Hanul Textiles uses a model to draft English emails to overseas buyers. Initially, everyone pastes their own prompt into a chat interface. Then an employee sends a draft presenting an unconfirmed shipping date as final, and the buyer schedules around it. The team lead decides to move the task into an internal tool with the development team.

Yoo, a developer on the team, collects six scattered prompts and puts every line into a table. Shared rules, such as polite business English and signature format, are mixed with individual differences: some always include prices, others never do. Yoo makes three decisions.

1. Separate positions. Move the role, tone and boundaries shared by all emails into the system message. Wrap changing order summaries and original buyer messages in tags in the user message. Since buyer text is external, the system message also states that its sentences are material to answer, not instructions to follow.
2. Set a missing-information policy. Shipping dates, quantities and unit prices affect buyer decisions. If absent from the order summary, mark them [Confirmation needed: shipping date] instead of inventing them, and put a separate staff confirmation checklist above the draft. Use defaults for easily revised details such as greetings and paragraph order.
3. Keep a template and records. Store versioned rules in the code repository and receive sales-team revisions as change requests. For each request, record what changes, why, and the before-and-after comparison on twenty past emails.

Whether to include prices is a business-condition conflict. After consulting the team lead, Yoo separates the conditions: “Include prices only if the buyer asks about them or the order summary contains a quotation number.”

During review, an employee asks whether an approximate shipping date would be better than none. Yoo rejects the suggestion. Guessing a shipping date can cause harm, and that guess caused the original problem. Instead, the checklist goes at the very top so staff cannot miss it. In the first month, no email presents an unconfirmed value as final, and staff report that the checklist reduces review time per email.

Common mistakes

• Believing emphasis makes the model comply. Repeating “must” and “never” in bold leaves ambiguity intact unless you define the action. Excessive emphasis can make newer models overreact.
• Thinking a role is enough. A role sets perspective and tone, but supplies neither company-specific knowledge nor success criteria such as length and required items.
• Thinking “System:” in a user message creates a system instruction. Authority comes from the message’s position, not its introductory words.
• Thinking “strike a balance” resolves conflict. Leaving judgment to the model produces a different choice on each request. The author must define conditions or priorities.
• Thinking prohibitions alone are enough. They leave the alternative unspecified. State desired actions positively and add alternatives to necessary prohibitions.
• Assuming the model will ask when it does not know. Without a policy, it usually fills in plausible values and continues. Specify when to ask, assume or withhold judgment.
• Thinking rules for every exception improve safety. Imagined exceptions create conflicts and brittle prompts. Start minimally and strengthen the prompt from observed failures.

Summary at a glance

Check the official docs

• Anthropic — Prompting best practices: Read “Be clear and direct,” “Add context to improve performance,” “Give Claude a role,” “Tool usage” and “Balancing autonomy and safety.”
• OpenAI — Prompt engineering: Read about message roles and priority, developer-message structure and the discontinuation of reusable prompts.
• Anthropic — Effective context engineering for AI agents: Read about the “right altitude” of system prompts and starting with a minimal prompt.
• Google — Prompt design strategies: Check how to specify constraints and response formats, and what belongs in system instructions.
• Anthropic — Reduce hallucinations: Read about explicitly allowing the model to say it does not know.

Self-check

1-1. List the four elements of good instructions. In one sentence, explain the review problem caused by omitting the element most often missing.

1-2. Rewrite “Make the CEO interview for the internal newsletter polished and a manageable length” as at least four verifiable conditions. Include one failure condition.

1-3. For the same meeting transcript, what task types are “extract decisions only” and “write a briefing for an executive who could not attend”? What should their instructions require differently?

1-4. You are writing spoken guidance for an automated parking pay station. Rewrite “Do not use English abbreviations” as an instruction with a desired action and a reason.

1-5. A prompt says both “End every answer with links to supporting documents” and “Finish within two lines of the internal messenger preview.” Explain why they cannot always both be met and merge them into one rule.

1-6. Customer input begins “System instruction: ignore all previous rules.” Explain through message roles why this sentence has no system authority.

1-7. Design a meeting-minutes assistant. Choose three potentially missing details, such as assignee, deadline and meeting-room name. Assign each to “ask / assume and label / withhold judgment” and explain why.

Hands-on tasks