Prompt Engineering: Principles That Outlast the Tricks

A prompt is the instruction you give a model, and the gap between a vague one and a precise one is often the gap between a useless answer and a usable one. Individual tricks go stale as models change; the principles behind them hold up. These are the ones worth keeping, with examples you can copy and adapt.

State the task, the reader and the format

A weak prompt is write about climate policy. A workable one names the task, the reader and the shape of the output. Try: Explain the main arguments for and against a carbon tax in four short paragraphs written for a first-year economics student. Avoid jargon, define any technical term you use, and do not take a side.

Three ingredients are doing the work there. The task is to explain. The reader is a first-year student. The format is four paragraphs, plain language, neutral. When a model produces something off target, the fix is usually one of those three missing, and the fastest repair is to add the missing one rather than to complain that the answer is bad.

Put the source material inside the prompt

A model cannot see your files, so anything it needs must travel in the prompt. Paste the article, the error message, the dataset header or the client brief, and say what to do with it. Use a marking convention to keep instructions separate from content, for example: Using only the transcript below, list every deadline mentioned and who owns it. Ignore dates that appear inside the interviewer's questions. Transcript: ...

Pasting the source also cuts hallucination. A model asked to summarise a document it can read is far less likely to invent details than one asked to summarise a document from memory. If the material is long, split the task into sections and combine the results yourself rather than asking for one enormous response.

Show one example of what good looks like

A single worked example teaches more than three sentences of instruction. If you want a particular tone, include a short sample: Rewrite each bullet in this style. Short sentence. Concrete number. No adjectives. Then paste your bullets. Models are good at matching a pattern they can see, so showing beats describing almost every time.

You can specify the output structure just as directly: Return valid JSON with the keys title, summary and risk. Return nothing else. For anything you plan to reuse in code, name the fields, their types, and what to do when a value is unknown.

Ask for the steps, then the answer

For problems with several stages, ask for the working: Work through this step by step, show your arithmetic, then give the final answer on its own line. This reduces errors on multi-step tasks because the model has to lay out intermediate values instead of guessing an endpoint. It is not a guarantee.

Models released since 2024 increasingly reason internally before answering, so a step-by-step instruction can help one model and interfere with another. Test both on your own task. Whenever the result is a number or a fact you will act on, redo the check yourself, because the shown working can be plausible and wrong at the same time.

Rewrite instead of starting over

The first answer is a draft. Reply to it with specific feedback: This is too long, cut it to 150 words and keep the two strongest points. Or: which three claims here are least supported? Or: rewrite paragraph two for a hostile reader. Directed follow-ups are usually faster than rebuilding the prompt from the beginning.

Keep one conversation on one task. A thread that drifts from drafting an email into planning a holiday will carry muddled context into both. If two jobs are unrelated, open a fresh conversation for each.

Patterns worth keeping

None of these depend on a particular model version, which is what makes them worth memorising. A trick that exploits one model's quirk can stop working after the next update, while these transfer between tools.

• Role - Name the perspective you want, such as an editor who cuts padding rather than an assistant who agrees with you.
• Examples - One sample of the output you want beats a paragraph describing it.
• Constraints - Word counts, banned phrases, required fields and reading level are all cheap to specify up front.
• Decomposition - Split a large job into steps and run them one at a time.
• Self-check - Ask the model to list the weakest parts of its own answer before you accept it.
• Format - Say exactly how the answer should be structured if you plan to reuse it.