A prompt is a specification
The useful frame is not "asking nicely". It is: you are writing a specification for a worker who is fast, well read, literal, and has no context about your business. Every ambiguity you leave will be resolved somehow, and you will not be consulted.
So the questions are the same as for any specification. What is the input? What exactly is the output? What should happen when the input is unexpected? What must never happen?
The parts, in the order they belong
The triple quotes are not decoration. A model has to be able to tell your instructions from the user’s text, and a clear delimiter is the first and weakest line of defence against the injection problem in the safety lesson.
1. Role and task Who is answering, and what the job is
2. Context The material to work from — retrieved, pasted, or both
3. Instructions What to do, and what not to do
4. Output format Exactly the shape expected, with an example
5. The input Clearly delimited from everything aboveYou classify support messages for a door manufacturer.
Categories: delivery, damage, measurement, billing, other.
Rules:
- Choose exactly one category.
- If the message fits none, use "other". Do not invent a category.
- Judge only from the message. Do not assume anything not written in it.
Reply with JSON only, no prose:
{"category": "delivery", "confidence": 0.0-1.0}
Message:
"""
{{message}}
"""What actually changes the output
The pattern in that table: structural changes work, theatrical ones do not. The escape hatch is the one people most often leave out — a model with no way to say "not in the context" will answer anyway, because answering is what it does.
| Change | Effect |
|---|---|
| Naming the exact output shape, with an example | Large. The most reliable single improvement |
| Giving the model an explicit "I do not know" option | Large. Without it, the only available move is to invent |
| Two or three worked examples | Large for format and edge cases — the next lesson |
| Stating what to do with bad input | Medium. Otherwise the behaviour is arbitrary |
| Splitting one prompt into two focused calls | Medium. Two simple jobs beat one complicated one |
| "Think step by step" on a reasoning model | Small to negative. It already does; you are duplicating it |
| "You are a world-class expert" | Negligible. It is folklore |
| Politeness, threats, tips, urgency | Negligible, and unmeasured when it is claimed |
Say what to do, not what to avoid
A negative instruction still puts the thing in the context, and it leaves the target undefined — "not verbose" could be anything. A positive one is checkable, and a checkable instruction is one your evaluation can test.
The same applies to length: "be concise" is unmeasurable; "at most two sentences" is a rule you can assert.
✗ Do not be verbose. Do not make things up. Do not use markdown.
✓ Reply in at most two sentences.
✓ If the answer is not in the context, reply exactly: NOT_FOUND
✓ Reply with plain text.And then measure it
Prompting is the part of this course where intuition is least reliable, because every change looks like an improvement when you try it on the example that motivated it. A prompt change without an evaluation set is a guess with extra confidence.
So the working method is: collect twenty real inputs with known-good answers, score the current prompt, change one thing, score again. The evaluation lesson builds that harness; this lesson is what you put through it.
And version prompts like code. They are a dependency with behaviour, they belong in the repository next to the tests that cover them, and a change to one should show up in a diff.