Instructions That Hold
Turn wishes into checkable instructions: name the behavior, pair every never with an instead, set role, audience, and voice, write the refusal, resolve conflicts, and cut every line that changes nothing.
Before this: L0 What a prompt is
- Rewrite a vague instruction into a specific one that names the observable behavior.
- Say what to do, not only what not to do, and explain why the positive form works better.
- Give the model a role, an audience, and a voice, and know when each matters.
- Define scope and write the refusal: what to do when the request is outside it.
- Order instructions by priority and keep the prompt as short as it can be.
Why this matters
Tessa sends Omar three drafts back with red pen on each. The first came from the instruction "do not be rude." The reply is so careful that it never answers the customer's question about the torn cover. The second came from "be concise." Two sentences, polite, and missing the exchange policy the customer needed. The third came from "never promise refunds." The customer in that email was owed a refund, and Draft refused her. Omar reads the three instructions again. None of them is wrong. None of them says what a good reply looks like either. Each is a wish about how the output should feel, and the model filled the gap with a guess. This lesson replaces wishes with behaviors: instructions that two people would agree were followed, or not.
1. Specific beats vague
An instruction is a sentence in the system prompt that changes what the model writes. Specificity is the property that makes an instruction checkable: an instruction is specific when two people reading the same reply would agree whether it was followed. "Be professional" fails that test. Tessa thinks a professional reply names the problem; Omar thinks it avoids blame. Both are defensible, so the model picks one, and one of them is unhappy.
The fix is to name the observable behavior. Observable means you could point at the sentence in the reply that satisfies it.
The test to run on every line: could you write a failing reply for it? If no reply could fail the instruction, the instruction is not doing anything.
2. Say what to do
A negative instruction tells the model what to avoid and leaves it to guess the alternative. "Never promise refunds" removes one sentence from the space of possible replies and says nothing about what goes in its place. The model has to choose, and its choices include refusing the refund outright, which is what happened to Tessa's third draft.
A positive instruction names the behavior you want. Pair every "never" with a "do this instead," so the model has a path, not only a wall.
Negatives are still useful. They mark the edge of what is allowed. They fail when they stand alone.
3. Role, audience, voice
Three settings shape every sentence the model writes, and each one is cheap to state.
The role is who the model writes as. The audience is who will read the output. The voice is how it sounds: sentence length, formality, which words and punctuation are allowed.
| Setting | Question | Draft's answer |
|---|---|---|
| Role | Who is writing? | The Elm Street store, on behalf of Bramble Books |
| Audience | Who reads it? | A customer who may be upset and has not heard back yet |
| Voice | How does it sound? | Short plain sentences, no exclamation marks, no marketing words |
When does each matter? Role matters when the model could write from the wrong side of the counter: as a chatbot, as the customer, as a generic company. Audience matters when the same fact should be said differently to different readers. Voice matters when Tessa is the reviewer, because she rejects replies that sound like a newsletter before she reads the second line.
4. Scope and refusal
Scope is the set of requests a feature handles. Refusal is the exact behavior when a request falls outside it. Most prompts define the first and forget the second, so the model fills the gap by trying anyway.
Draft's scope: reply to a customer email about one existing order, using the order record. Outside scope: cancelling or changing an order, issuing refunds, quoting policy that is not in the prompt, anything about a different order.
The refusal is not "decline politely." It is a behavior with parts: say what cannot be done, say why in one sentence, name what a person can do, and stop.
5. Priority and ordering
Instructions conflict. "Be brief" fights "include the exchange policy." "Answer the customer's question" fights "do not cancel shipped orders" when the question is a cancellation. A priority is an explicit statement of which rule wins. Without one, the model resolves the conflict by whichever instruction it happened to weigh more heavily, and that changes between runs.
Ordering matters too. Put the rules that matter most where they are read: near the top, and again at the end of the system prompt, closest to the data. Group by topic so a rule about refunds sits beside the other refund rules, not between a voice rule and a formatting rule.
6. The new-hire test
Here is a test you can run without a model. Hand the prompt and the order record to a new store employee on their first day, with no other training. Could they write the reply? If they could not, the model cannot either, because it has the same information they do.
This is the new-hire test. It catches missing facts rather than bad wording. The employee reads "offer the exchange option" and asks: what is the exchange option? Fourteen days? Thirty? Does the customer pay return postage? If the answer is not in the prompt or the record, the model will invent one.
7. Length
Prompt length is best measured in sentences that change an output, not in lines. A sentence earns its place by producing a different reply than the prompt would produce without it. Everything else costs tokens, competes for attention with the instructions that matter, and gives the model more places to find a contradiction.
Three kinds of sentence to cut. Restatements: "be accurate" after a rule that says which fields to quote. Compliments: "you are an expert customer service writer" changes nothing that the voice rules do not already set. Anything the data already shows: "the order record contains the delivery date" when the record is in the request.
8. Before and after
Here is the rewritten prompts/draft.system.md, all 28 lines. The notes after it say which section of this lesson each part came from.
# Draft: reply to a customer email
## Role and audience
You write as the Elm Street store of Bramble Books, to a customer who
may be upset. Tessa reviews every reply before it is sent.
## Voice
- Use "we", never "I". Sentences under 20 words.
- No exclamation marks. No "amazing", "delighted", or "reach out".
- Close with "Tessa, Elm Street" on its own line.
## Shape of a reply
Open with the customer's first name. One sentence naming the problem
in their words. Then the options, one per line. Then the close.
## Exchange policy (the only policy you may state)
- Damaged or wrong items: exchange within 14 days of delivery.
- Bramble pays return postage for damaged items.
- The customer chooses a replacement copy or store credit.
## Refunds
Never state a refund amount. When a refund may apply, say a store
manager will confirm the amount within one business day.
## Outside scope
Cancelling, changing, or refunding an order, and any policy not above.
Say which part cannot be done and why, using the order record. Name
what Tessa can do. End with "Tessa: outside scope, needs a decision."
## Priority (higher wins)
1. Refunds and Outside scope rules.
2. If the order has shipped, Outside scope wins over answering.
3. Include the exchange policy whenever the email mentions damage.
Annotations:
- Role and audience, Voice: section 3. Every voice line is checkable with a highlighter.
- Shape of a reply: section 1. The vague "be professional" became three observable steps.
- Exchange policy: section 6. This is the paragraph the new-hire test found missing.
- Refunds: section 2. The never is paired with an instead.
- Outside scope: section 4. The refusal has parts: what, why, who, and a flag.
- Priority: section 5. Rule 2 is what fixes DR-2; rule 3 is what fixes "be concise."
What is gone: "be helpful," "be accurate," "you are an expert," and the paragraph about Bramble's founding. None of them ever changed a reply.
src/llm/draft.ts reads this file and sends it as the system field of the call, unchanged. The order record and the email go in the user turn, which is L2's subject. Every provider and gateway has an equivalent field; the instructions inside it are what this lesson is about.
Summary
- An instruction is specific when two readers would agree whether a reply followed it; name observable behavior, not feelings about it.
- Pair every "never" with a "do this instead," so the model has a path and not only a wall.
- State role, audience, and voice as checkable rules; Tessa grades voice with a highlighter.
- Define scope, and write the refusal as a behavior: what cannot be done, why, what Tessa can do, and a flag for the reviewer.
- Resolve conflicts with an explicit priority block, run the new-hire test for missing facts, and keep only the lines that change an output.
Key terms in this lesson
Check your understanding
Pick an answer to see why it is right or wrong. These are graded in code, instantly.
Apply it
Write your answer in your own words. Eve grades it against a rubric and gives you feedback, the same way an LLM judge works in Lesson 5.
Rewrite "do not be rude" as two positive, specific instructions for Draft.
Write the scope and refusal section of Draft's system prompt. State what Draft handles, list three things it does not handle, and give the exact behavior for each of the three.
Homework 1: Rewrite Draft's system prompt
Rewrite prompts/draft.system.md from scratch, under 40 lines, for the Draft feature: it replies to a customer email about one existing order, using the order record, for Tessa to approve before sending.
Your prompt must include:
- A role, an audience, and a voice, each stated as checkable rules.
- At least six specific instructions. For each, you should be able to say what reply it would change for DR-1, DR-2, or DR-3.
- Every negative instruction ("never", "do not") paired with the positive behavior that replaces it.
- A scope section naming what Draft handles, and a refusal behavior for requests outside it: what cannot be done, why, what Tessa can do, and a flag she sees.
- A priority block that resolves at least one conflict between two of your own instructions.
After the prompt, add a two-sentence note: what the new-hire test would catch in your prompt if a new employee had only your prompt and the order record for DR-1.
Submit the prompt as a markdown block and the note as plain text.
- The rewritten `prompts/draft.system.md` as a markdown block, under 40 lines
- A two-sentence note on what the new-hire test would catch
Paste your homework write-up below. Include every deliverable.
Instructor notes(for whoever is teaching this lesson)
Talking points
- Tessa's three red-pen drafts are the thread. Each instruction was a wish about how the reply should feel.
- The specificity test: would two readers agree whether the reply followed it? If they could argue, the model can too.
- A never is a wall with a hole next to it. Pair it with an instead.
- Voice rules should be gradable with a highlighter; if one needs judgment, split it.
- A refusal is a behavior with parts, not a no. DR-2 shows all four: what, why from the record, what Tessa can do, the flag.
- Priority is where conflicts get decided once. Rule 2 rescues DR-2, rule 3 rescues "be concise."
- The new-hire test finds missing facts; delete-and-compare finds dead lines. Both are needed.
Live demo idea
Put Omar's 60-line prompt on screen with DR-1's record and email. Run the call three times and read the openings aloud. Rewrite "be professional" live into the three observable steps and run again. Delete "you are an expert customer service writer" and run all three cases; nothing changes. Delete the exchange policy lines and run DR-1; the reply guesses at a return window. Close with a volunteer who has never seen Draft writing the DR-2 reply by hand from the 28-line prompt.
Common misconceptions
- "Specific means long." Specific means checkable. "No exclamation marks" is four words and fully specific.
- "Negative instructions do not work." They work as edges. They fail when nothing says what fills the space they clear.
- "The refusal is a polite decline." It is a behavior: what, why, what Tessa can do, and a flag. A decline with no next step is a silent refusal in a nicer voice.
- "The model will figure out which rule matters more." It will, differently on each run. The priority block decides once.
- "Adding a rule can only help." Every line costs tokens and can contradict another line. Lines that change no output are cut.
Timing
Fifty-five minutes: story and section 1, seven; say what to do, six; role, audience, voice, seven; scope and refusal, eight; priority and ordering, six; the new-hire test, six; length, five; before and after, ten.
If you only have 20 minutes
Rewrite the three red-pen instructions live: "be professional" into observable steps, "never promise refunds" into a paired instruction, "be concise" into a priority rule (ten minutes). Walk the 28-line prompt's annotations (six minutes). Set the new-hire test as the take-home: give the prompt and the DR-1 record to someone who has never seen Draft and bring back their first question (four minutes). Assign sections 4 and 7 as reading before HW1.