How to write better AI prompts: brief it like a contractor

The contractor you have never met

Suppose you have hired a very capable contractor to do a piece of work. They are quick, widely read and eager to please. They have never worked at your organisation, never met your customers, do not know your house style, and will not ask clarifying questions unless you invite them to. They will start the moment you stop talking, and they will fill any gap in your instructions with their best guess about what a typical client in your position would want.

Working with a large language model is remarkably like this, and the comparison explains most of what goes wrong. When people complain that a model produced something generic, wordy or subtly off-target, the cause is almost always that they gave it a generic, thin or ambiguous brief. The model did exactly what a stranger would do with the same instructions: it guessed.

The shift that turns a casual user into a practitioner is to stop treating the prompt as a search query and start treating it as a brief. A search query is a few keywords you throw at an index. A brief is a document that transfers what is in your head into someone else's head well enough for them to do the work without you. That transfer is a skill, and like any skill it has components you can practise deliberately.

Five levers you can always pull

The first lever is clarity: say exactly what you want done, in plain language, as an outcome, not a topic. Compare a request for something about our returns policy with a request to write the customer-facing paragraph that explains our thirty-day returns window to a shopper who is about to check out. The second version has an action, a reader and a purpose.

The second lever is context: everything the contractor would need to know that lives only in your head or your files. Who the audience is, what has already been tried, what the source material says, what the organisation cares about, what a good result looks like. A model has no access to any of this unless you supply it. Practitioners routinely paste in the relevant email thread, the existing document, or the three facts the output must hinge on, because they know the alternative is a confident guess.

The third lever is constraints: format, length, tone, what to include and what to leave out. Constraints are not a cage; they are how you make the output land in a shape you can use. Two hundred words, no headings, written in the second person, no mention of pricing is a brief a contractor can hit on the first attempt. Without it, you get whatever shape the model considers typical, and typical is rarely what you need.

The fourth lever is examples. Showing beats telling. One or two examples of the output you want, or of past work you consider good, transfer your standards far faster than adjectives ever could. If you want a summary that reads like your team's briefing notes, paste in one of your team's briefing notes and say, like this.

The fifth lever is iteration. The first output is a draft of the conversation, not the end of it. A practitioner reads the first result, works out which of the four earlier levers was under-specified, and pulls it. Too generic means missing context. Wrong shape means missing constraints. Wrong standard means missing examples. Wrong task altogether means unclear instruction. Treating the second turn as a diagnosis instead of a complaint is what makes iteration productive.

A worked rewrite, lever by lever

Many people have typed a request like this one: summarise this meeting. Attached is a transcript. The output is competent, generic and unusable, because the model does not know who the summary is for, what decisions matter, or how long it should be. Rebuild it one lever at a time.

Notice what changed. The task is now an action with a real reader. The model knows what the reader cares about, so it can weight the content. It knows the shape, so it will not drift into a page of bullet points. It has a sample, so it will match the register. And the practitioner has already planned the verification step, because a note with a wrong date is worse than no note at all.

Notice also what did not change: no clever phrasing, nothing that depends on which model is running. The test of a good prompt is simple: if you would be embarrassed to hand it to a sharp human assistant because it is vague, it is too vague for a model too.

How to apply this tomorrow

Pick one task you already give to a model regularly and write the brief once, properly, as a reusable template with blanks for the parts that change. Most practitioners find that three or four such templates cover the bulk of their routine use, and that the quality jump from a template built with all five levers is larger than any jump they have seen from switching tools.

Then adopt one habit: before you press send, read the prompt as if you were the contractor. Ask what you would have to guess. If you can name a guess, you can close it in one sentence. If you cannot name any, you are ready. This thirty-second review is the single highest-return practice in the whole toolkit, and it works regardless of which model you are using or how capable models become.