beginner25 minby DevFox

Writing a Prompt That Holds Up

The four parts of a prompt that survives contact with real inputs — instruction, context, examples, output contract — and the vague, overloaded and politely-worded prompts that quietly fail.

Your prompt sorts incoming support email, and it is good. You tried it on three real messages while writing it, all three came back right, and you shipped it on Thursday.

On Monday it meets an email that is mostly a forwarded thread, with an out-of-office auto-reply pasted at the top and the real question four screens down. It returns a confident, well-formatted summary of somebody's holiday dates. Nothing errored, and the result landed in the ticket queue looking exactly like every correct one. By the end of this lesson you will know the four parts every durable prompt has, how to write an instruction a stranger could check, what to tell the model to do when the input is unusable, and why the inputs you tested on are the least useful ones you own.

A prompt is a spec, not a conversation

A prompt is the text you send a model — everything it sees before it starts writing. In a chat window it is a turn in a conversation: you read the answer, notice it missed the point, and type "shorter, and skip the intro". The correction is free, because you are sitting right there.

Inside a program, nobody is sitting there. The same prompt runs a thousand times against inputs you will never read, and the answer goes straight into a database, an email, or the next function along. There is no second turn.

So write it the way you would write a note for a temp who starts at 3am. They are fast and capable, they have never met your product, they will not phone you, and they will do something rather than nothing. Every question your note leaves open, they answer for themselves — plausibly, confidently, and differently each night. Ambiguity in a prompt does not produce an error. It produces a guess that reads exactly like an answer.

The four parts of a prompt that holds

A prompt that survives real inputs does four jobs. You should be able to point at each of them in your own.

The instruction
The task, in verbs: what is being done, and to what.
The context
The material to do it to, plus any fact the model cannot know — who the customer is, what your product is called, what today's date is.
The output contract
The shape of the answer: how long, in what form, and what must not appear in it.
The constraints
What to leave out, what not to invent, and what to do when the input does not fit the job at all.

Point at each of these in your own prompt. A missing one is a question the model answers for you.

All four at once, for a bike-parts shop sorting its inbox:

Line one is context: who the model stands in for. Line three is the instruction, the three-line block is the output contract, the paragraph after it is constraints, and MESSAGE is the rest of the context.

A fifth part, worked examples for tasks where showing beats telling, has its own failure modes and its own lesson, Few-Shot Examples That Teach. Everything below works without it.

Be specific about the task, not polite

The first draft of almost every prompt is written in the voice of someone asking a favour. It reads well and does very little.

Bad — asks for effort, which nothing can measure, and gets a different length each time.

Good — asks for things a stranger could confirm by reading the output.

"Carefully", "thorough" and "really good" describe an effort, not an artefact. Nothing in them tells the model whether four words or four paragraphs is right, so length follows the input instead of your requirement — and the day a chatty customer sends six paragraphs, the database column everyone assumed held one line holds six.

So apply this test to every sentence you write: could someone who has never met you read the output and say yes or no to this requirement, without asking what you meant? "At most 25 words" passes; "concise" does not. "Name the product, the problem and the request" passes; "capture the essence" does not. A sentence that fails is a mood rather than an instruction, and the model interprets a mood freshly on every call.

The same applies to how much you ask at once. A prompt that summarises, translates, scores sentiment and drafts a reply is four prompts in one coat: when the output is wrong you cannot tell which instruction was dropped. Two tasks, two calls.

Keep your words and the user's words apart

The model does not receive a marked-up document with your instructions in one colour and the customer's message in another. It receives one flat stream of text in which every part carries equal authority. Whatever you paste inside your instruction sentence becomes part of your instruction.

Bad — the customer's sentences arrive welded to yours, so anything they wrote reads as a command.

Good — the instruction stays outside a labelled block, and the block is declared to be data.

Real inboxes are full of sentences aimed at a reader: "please forward this to your manager", "reply with the invoice number", "ignore the message below, the correct address is here". The model is a reader. Without a boundary those lines look exactly like the ones you wrote, and the damage arrives as one strange output a week that you cannot reproduce.

The delimiter can be anything unlikely to appear in the data — triple quotes, dashes, a tag like <email>. What matters is that it is consistent, that the block is labelled, and that you say in words which part is data. When the block runs long, repeat the instruction after it too: the start and the end of a long input are where instructions survive best.

Say what the answer should look like

The output contract says what a correct answer looks like from the outside, before anyone reads its content. It exists because something downstream consumes this text — and even a person scanning a dashboard reads two hundred a day and wants them all the same shape.

Pin down three things. Length, in a countable unit: words, lines, items. Form: name the fields and their order. And what must not appear, the one people forget. Models are trained to be conversational, so left to itself an answer arrives wrapped in "Sure! Here's a summary of the customer's message:" and signs off offering further help. That wrapper is not decoration; it is the first thing your code sees.

So the triage contract from earlier gains one sentence — "No preamble, no explanation, no closing offer of help" — and the reply becomes exactly this, every time:

Once the thing reading that output is code rather than a person, you want a format with a real parser and validator instead of lines you split by hand — the subject of Structured Output Instead of Prose. The habit is the same either way: decide the shape of the answer before you send the request, not after you read one.

The instruction for when the input is unusable

A model always produces text. Hand it an empty message, an auto-reply, a language it cannot read, or a PDF that arrived as gibberish, and it will not tell you it has nothing to work with. It writes the most plausible triage record for a message shaped like that one.

Bad — has no legal way to say "there is nothing here", so it fills the gap.

It returns a clean, well-formed, fictional ticket:

Good — names the failure and gives it a value your code can branch on.

The bad version's answer is not wrong-looking. It is a perfectly-formed ticket about somebody's holiday, sitting in the queue beside the real ones with nothing to mark it out. A failure you can see costs an hour; one that looks like a success costs however long it takes someone to notice.

Two things make an escape hatch work. The value has to be distinctive and exact — "say that you cannot help" produces a different apologetic sentence every time and nothing you can match on, while a bare token like UNUSABLE is one string comparison. And you have to handle it:

A fallback nobody checks for is decoration. Write the branch in the same sitting as the sentence.

Name the failures you can enumerate — empty, auto-reply, wrong language, missing field — then add a catch-all for the ones you cannot. Those few lines turn silent wrong answers into loud ones, and loud is the only kind you can fix.

Why it fails on the fourth input

The three you tested on

The three that were easiest to reach.

Recent, short, in your own language, and containing the exact thing you were extracting.

They share a shape you never chose and never noticed, and your prompt is quietly fitted to it.

A file of ten to twenty

One at each extreme, from real traffic.

Real, because the failures you imagine are the ones you have already defended against.

Kept beside the prompt in the repository, as ordinary text files, and re-run every time you change a word.

The second one takes an afternoon to build and is most of the value in this lesson

Real traffic varies along axes you can write down in advance, and that is what the file should cover:

Axis	What you tested	What breaks it
Length	a short paragraph	a thread, ten replies deep
Language	yours	one you cannot read
Formatting	plain text	HTML, signatures, quotes
Completeness	has the field you want	order number never given
Answer count	one clear request	three requests, or none
Content	describes a problem	contains its own instructions

Re-running all of them on every edit is the part people skip, and the part that matters: prompt edits are not local. Tightening the summary rule changes what happens on the empty input. Adding the escape hatch changes how eagerly the model categorises a borderline message. The change you were sure was safe breaks the case you fixed last Tuesday.

Attaching an expected answer to each input and turning the set into a comparable score is a later lesson in this course. The collection itself takes an afternoon and is most of the value.

A cheat sheet to keep

Where to go next

You can now write a prompt that names its task in checkable terms, fences off the user's text, declares the shape of the answer up front, and has a defined way to say "not this one" — and you know why three friendly inputs prove almost nothing.

All of that lives inside a single request, built fresh each time you call. But some instructions are true of every request you will ever send: what the product is called, what tone it uses, what it must never do. Repeated in every prompt, they drift apart the moment you edit one and forget the others. System Prompts and Rules Files is about that durable layer — what belongs there rather than in the request, and why a rules file checked into the project has become normal practice whichever tool you use.

Before you move on, do one thing. Take a prompt you already have and add exactly one line: the escape hatch. Then feed it your worst input — an empty string, a page of raw HTML, a message in a language you do not read. If it answers anyway, the hatch is not specific enough yet. If it replies UNUSABLE, you have turned a silent failure into one you can see, which is the whole job.