Prompts That Hold

Same prompt, different Tuesday

On Monday it wrote six client update emails you’d have happily sent. On Tuesday it wrote six paragraphs of pleasant mush. You checked the prompt twice, and it was identical. Then you pasted it into Slack for a colleague, and hers came out worse than both.

So what changed? Nothing in the prompt. Everything around it.

Monday’s prompt was carrying luggage you couldn’t see. Twenty messages up that thread, you’d pasted in the client’s brief, corrected the tone twice, and said “shorter, and stop using the word partnership”. None of that was in the prompt, but all of it was in the output. On Tuesday you started a new chat, and none of it existed anymore. Your colleague never had any of it in the first place.

I think this is the bit most people miss. A prompt that works once is really a prompt plus a conversation. A prompt that holds carries its own context with it.

Four things a lucky prompt is usually missing

The context lived in the chat history. Facts the model couldn’t possibly guess, which you supplied in passing and never wrote down.

There are no constraints. You know six ways this output goes wrong, because you’ve seen them. The prompt mentions none of them, so you correct the same six things by hand every time.

There are no examples. You described the tone you wanted, and descriptions of tone are unreliable. An actual sample of the tone is much more reliable.

There’s no definition of done. Without one, the model decides when it’s finished, and it decides differently on Tuesday.

Seven parts, each doing one job

ROLE. This sets the vocabulary and the default assumptions. “You are a bookkeeper writing to a small business owner” produces different word choices from “you are a copywriter”.

CONTEXT. The facts it can’t guess: the client, the audience, what happened, what’s already been said. This is where the stuff from your chat history goes to live permanently.

TASK. One verb, one deliverable. If you need two things, write two prompts. A prompt trying to do three jobs tends to do all three worse than it would do one.

CONSTRAINTS. Your corrections, written down. Every time you fix something by hand, that fix becomes a line here. This section grows over time, and that’s a good sign. For the banned-words line, start from the list in Kill the AI Tells and add whatever your industry overuses.

EXAMPLES. One output you’d have sent. Ideally also one you wouldn’t, labelled, with a note on why. Examples do the job adjectives can’t. If you’ve built a voice file, its before-and-after pairs are ready to paste in here.

OUTPUT FORMAT. The exact shape you want back, so you can use it without reformatting. Headings, field names, length, no preamble.

STOP CONDITIONS. What it should do when it can’t do the task properly. Without this, it invents something confident and plausible. With it, you get “MISSING: the delivery date”, which is far more useful.

Steal this skeleton and fill the slots

Square brackets mark the slots you fill in the INPUTS block each time it runs. Angle brackets are the parts you replace once, while you’re building it.

INPUTS
CLIENT_NAME:
AUDIENCE:
SOURCE_MATERIAL:
PRIOR_CONTEXT:
WORD_COUNT:
SENSITIVITIES: (optional, default: none)

ROLE
You are <who is writing, in one line> writing for [AUDIENCE].

CONTEXT
- Client: [CLIENT_NAME]
- What happened: [SOURCE_MATERIAL]
- What they already know: [PRIOR_CONTEXT]
- Anything sensitive to avoid: [SENSITIVITIES]

TASK
Write one <deliverable>. Do this and nothing else.

CONSTRAINTS
- Length: [WORD_COUNT] words, hard limit.
- Never use these words: <your banned list>
- Never <a mistake you keep correcting by hand>
- Never <another one>
- If a fact isn't in CONTEXT, don't include it. Don't estimate.

EXAMPLES
Good, and the standard to match:
<an output you'd have sent>

Bad, and why:
<an output you wouldn't send>
<what's wrong with it>

OUTPUT FORMAT
<the exact structure you want back>
No preamble and no commentary on your choices.

STOP CONDITIONS
If CONTEXT is missing something you need, stop. Output the word MISSING,
then list the specific gaps. Do not proceed with assumptions.

A prompt only you can fill in isn’t finished

Three small conventions make the difference between a prompt one person can use and one a whole team can.

1. Name each slot for what goes in it, not what it does. [CLIENT_NAME], not [INSERT_HERE].
2. Mark optional slots (optional) and say what the default is. SENSITIVITIES: (optional, default: none). Otherwise someone leaves it blank, and the model has to guess what blank means.
3. Every slot appears once, at the top, in the INPUTS block, and the body refers to it by name. That way the person running it edits one block, not six spots scattered through the prompt.

Run five real inputs before you trust it

This is the step that separates a prompt you hope works from one you know works. Before you rely on it, collect five real inputs and run the prompt against all of them.

Choose them on purpose. Two typical cases. One awkward one, like a long rambling transcript or an enquiry written in fragments. One written by someone else, in a different style. And one where the right answer is to refuse, so you can check the stop conditions actually fire instead of the model inventing its way out.

Write down what a pass looks like before you run anything, or you’ll grade it generously. I know I would.

Test	Input	Passes if
1	Clean 20-minute call transcript	Under the word count, no banned words, every fact traceable to the source
2	Second typical transcript	Same standard, no drift in tone
3	Rambling 50-minute transcript with two off-topic tangents	Ignores tangents, no invented dates
4	Transcript with the deliverable date never mentioned	Outputs MISSING, doesn’t guess
5	Notes from a colleague, different writing style	Output reads the same as tests 1 and 2

Run the whole set again whenever you edit the prompt, whenever you switch models, and before you hand it to anyone else. It takes about ten minutes, and it’s the only real evidence you’ve got.

Filled in, it’s an update you’d actually send

INPUTS
CLIENT_NAME: Brightwater Dental
AUDIENCE: practice owner, not technical, reads on a phone
SOURCE_MATERIAL: (paste this week's project notes here)
PRIOR_CONTEXT: we agreed the booking flow scope on 2 September
WORD_COUNT: 180
SENSITIVITIES: jargon. They've asked twice for plain English.

ROLE
You are an account lead writing the weekly update for [AUDIENCE].
They're busy and hate being managed.

CONTEXT
- Client: [CLIENT_NAME]
- What happened this week: [SOURCE_MATERIAL]
- What they already know: [PRIOR_CONTEXT]
- Anything sensitive to avoid: [SENSITIVITIES]

TASK
Write one weekly update email. Do this and nothing else.

CONSTRAINTS
- Length: [WORD_COUNT] words, hard limit.
- Never use these words: circle back, touch base, bandwidth, moving forward
- Never open with "Hope you're well".
- Never describe a task as "in progress" without saying what's left.
- If a fact isn't in CONTEXT, don't include it. Don't estimate.

EXAMPLES
Good, and the standard to match:
"The booking flow is built and on the test site. Two things left: the
confirmation email wording, and the deposit step. Both with me. You don't
need to do anything this week."

Bad, and why:
"We've made great progress across several workstreams."
Says nothing the client can check.

OUTPUT FORMAT
A subject line, then two short paragraphs: what's done, and what's left.
End with one line saying what we need from them, or "Nothing needed from
you this week."
No preamble and no commentary on your choices.

STOP CONDITIONS
If CONTEXT is missing something you need, or SOURCE_MATERIAL has no
completed work in it, stop. Output the word MISSING, then list the
specific gaps. Do not proceed with assumptions.

(Brightwater Dental is a made-up example.)

When not to bother

• You’re thinking, not producing. Exploratory back-and-forth is a conversation, and structuring it kills the useful wandering.
• It’s a one-off. Writing a prompt that holds takes maybe half an hour. Doing a one-off task takes fifteen minutes. If the same job comes round a third time, it’s stopped being a one-off, and The Three Repeats Method is how you’ll notice.
• You want to be surprised. Constraints narrow the output. That’s the whole point, and it’s the wrong point for idea generation.
• You haven’t done the task yourself enough times yet. You can’t write constraints for failure modes you’ve never seen. Do it by hand at least three times first, note every correction you make, and write the prompt from that list.

What you’ve got now

A skeleton you can paste into any model, with slots that someone who wasn’t in the room can fill in. And a test set that tells you it holds before a client finds out it doesn’t.

Take the prompt you’ve rewritten most this month. Rebuild it on the skeleton, and run five test inputs through it before Friday.