How to write a better prompt: the five sections that do the work

Most bad prompts are not badly worded. They are badly shaped — a paragraph containing five different kinds of information, none of them labelled, which the model has to sort before it can start. Fixing the shape is worth more than any amount of rewording.

The five sections

Almost every useful request to a model decomposes into the same five parts. You do not need all five every time, and you do not need them in this order — but if a prompt is going badly, it is usually because one of them is missing rather than because the sentences were clumsy.

Goal — the one sentence version

What should be true when this is done. One sentence. If you cannot write it in one sentence, you have two goals, and the model will pick whichever one you happened to describe in more detail.

Context — what the model cannot see

The facts that make the goal legible. Which file, which framework, what went wrong, what you already tried. This is the section people skip, because the context is obvious to the person holding it. It is not obvious to a model that has never seen your repository.

Tasks — the steps you actually want

Numbered, and only where the order matters. Two tasks in one bullet is how you end up with one of them done.

Constraints — the things not to do

The highest-value and most-skipped section. “Don’t touch the email signup path.” “No new dependencies.” “Keep the existing test names.” A model has no idea which parts of your system are load-bearing, and it will happily rewrite something correct on its way to fixing something broken.

Done when — how you will check

The acceptance test, in your own words. “A fresh Google signup lands on the workspace, not a 404.” This does two things: it tells the model when to stop, and it forces you to decide what success is before you have an answer in front of you to be impressed by.

Why shape beats wording

Long prompts are not the problem. Undifferentiated prompts are. When goal, context and constraints arrive as one paragraph, everything in it reads as equally important — so the constraint you cared most about sits at the same weight as an aside about what you had for lunch.

A prompt is not an instruction. It is a brief, and briefs have sections for the same reason contracts do.

Here is the same request in both shapes.

Nothing was added and nothing was summarised away. The same words are filed. That is the entire difference, and it is usually the difference between one round trip and four.

Four rules that survive contact

• Say what not to do. Constraints are cheap to write and expensive to omit. Most disappointing outputs are technically responsive to what was asked.
• Name things exactly.“The pipeline” means nothing; src/main/pipeline.ts means one thing. Every ambiguous noun is a coin flip you are delegating.
• Give one example over three adjectives.“Terse, technical, no preamble” is three guesses. One sample of the output you want is not.
• Do not pad.Politeness, role-play preambles and “think step by step” on a task that needs no steps are tokens spent buying nothing.

The catch

Everything above is easy to agree with and tedious to do. Writing five labelled sections for a thirty-second question is slower than typing the question, so most people type the question — and then spend three follow-ups supplying, one at a time, the context they could have given once.

That is the gap Yappr is built for. You say the messy version out loud, because talking is the fastest way to get everything out of your head, and the structure gets applied on the way to the page. Goal, Context, Constraints and Tasks — and Verify, when you said how you would check it — from the same ramble you would have typed as one line.