The full prompting process

Magic phrases come and go with each model generation. What keeps working is a process: knowing exactly what you want, giving the model what it needs to deliver it, and checking the result against something more reliable than your first impression.

The seven steps below scale from a one-off email to a prompt that runs thousands of times a day inside a product. For a quick task you might do them in your head in thirty seconds. For anything you will reuse, do them properly.

Write one or two sentences that describe the outcome, not the activity. 'Summarise this report' is an activity. 'Give the board a one-page brief they can decide from in five minutes, with the three risks that need a decision' is an outcome.

Then list the success criteria you would use to judge the output if a colleague had written it: length, audience, what must be included, what must never appear, and how you will check it. These criteria become your prompt's requirements and, later, your evaluation rubric.

The model knows a lot about the world and nothing about your situation. The single biggest quality lever is giving it the context a smart new colleague would need: who the output is for, why it matters, the source material, constraints, and examples of what good looks like.

Gather real material rather than describing it. Paste the actual policy, the actual data, the actual previous email. If you have tried before, include what went wrong.

Put the pieces in a predictable order so both you and the model can find them. For long inputs, put the material first and the question last, as lab prompting guides generally recommend. Use tags to separate your instructions from the content you are pasting in.

Explain the reasons behind important rules. A rule with a reason generalises to cases you did not list; a bare rule in capital letters often does not.

Collect five to twenty real inputs before you judge the prompt: typical cases, a couple of awkward ones, and at least one that should make the model say 'I can't do that from what I have'. Run the prompt on all of them and read every output.

A prompt that is perfect on your favourite example often fails on the third. Testing on a set is the difference between a demo and something you can rely on.

When outputs disappoint, name the failure before you edit. Generic output usually means missing context or examples. Wrong facts mean missing sources. Wrong format means the shape was not specified precisely, or a schema is needed. Inconsistency across runs means criteria are vague.

Change one thing, re-run the whole set and keep notes. It is common for a change you were sure would help to make other cases worse; you only notice if you re-run everything.

Turn your success criteria from step 1 into checks. Some can be automatic (valid JSON, under 200 words, includes a citation). Others need a rubric applied by a person or a carefully prompted model. The 'Testing prompts' module in this path covers golden sets, rubrics and judge prompts in depth.

Decide in advance what pass rate is good enough for the stakes. A draft-generating prompt can tolerate occasional misses because a human edits the output; a prompt that writes directly to customers cannot.

A prompt you reuse belongs in a template with named variables, a version number and a short note on what it is for and what it was tested on. Store it where your team can find it, not in someone's chat history.

Models change underneath you. When you switch models or a provider updates one, re-run your test set before assuming the prompt still works. Watch real outputs for new failure types and add them to the set.