"Prompt engineering" has acquired an unfortunate mystique — as though there are secret phrases that unlock better results. There are not. A prompt is a specification, and writing a good one requires the same skills as briefing a capable new colleague who cannot ask you follow-up questions.
The useful analogy
Imagine handing a task to someone competent and well-read who has just joined, knows nothing about your company, cannot see your screen, and will not come back with questions. They will simply do the task based on what you wrote.
Everything that follows comes from taking that seriously.
What weak prompts leave out
The audience. "Summarise this report" produces something generic. "Summarise this report for a customer who is angry about the delay and does not care about the technical causes" produces something usable.
The purpose. Why does this text exist? A summary for a decision is different from a summary for the archive.
The constraints. Length, tone, format, what must be included, what must not be mentioned. If you have a house style, state it — the model cannot infer it.
The definition of done. What would make this a good answer rather than an acceptable one?
Show rather than describe
The most reliable improvement available is including an example of the output you want. Describing a style in adjectives is imprecise; showing one good example communicates format, tone and level of detail at once.
Two or three examples are better than one, and they resolve ambiguity you did not know was there. If a process runs repeatedly, curating a small set of good examples is usually the highest-value work you can do on it.
Give it the material
A frequent mistake is asking about information the model does not have and cannot get. It does not know your prices, your customer's history or what was agreed in a meeting last Tuesday. If the answer depends on those, they must be in the prompt.
This is the whole idea behind retrieval-based systems: fetch the relevant documents first, then ask the question with those documents supplied.
Let it decline
If you ask a question that cannot be answered from what you provided, you will usually get an answer anyway — a plausible one, invented. Explicitly permitting "the documents do not contain this" makes that outcome far more likely than silent fabrication.
This single instruction removes a meaningful share of hallucination problems in document-based systems.
Structure long prompts
When a prompt contains instructions, context documents and a question, separate them clearly with headings or delimiters. Otherwise the boundary between "text to work on" and "instructions to follow" becomes ambiguous — and a document containing instruction-like sentences can get read as instruction.
Iterate on the failures
Write a first version, run it on ten real cases rather than one, and look at what went wrong. Then fix the prompt to address the actual failure. This loop, repeated a few times, outperforms any amount of theorising about wording.
Keep the ten cases. When you change the prompt later, they tell you whether you improved things or merely moved the problem.
Treat it as an asset
A prompt that reliably runs part of your business is documentation of how that work is done. Store it in version control, review changes, and note why each instruction is there. Prompts that live in someone's chat history are lost when they leave.
