Prompt engineering that actually works: a practical foundation
Forget the magic incantations. Good prompting is a small set of repeatable habits. Here's the foundation, with examples.
- 01Clear instructions, relevant context and an explicit output format do more than any clever phrasing.
- 02Show the model examples of what you want — demonstration beats description.
- 03Iterate on prompts like code: change one thing, test, keep what works.

Drop the magic-words mindset
The internet is full of 'secret prompts' that supposedly unlock hidden power. Ignore most of it. Effective prompting isn't about incantations; it's about communicating a task clearly enough that a capable but literal-minded collaborator can do it well. Once you internalise that frame, the techniques fall out naturally.
Here's the foundation, in the order it matters.
1. State the task and the role plainly
Ambiguity is the enemy. The single biggest improvement most people can make is simply being specific about what they want.
Weak: "Write about our product."
Stronger: "Write a 100-word product description for a waterproof hiking backpack aimed at weekend walkers. Emphasise durability and comfort. Friendly, confident tone — no hype words like 'revolutionary.'"
The second version isn't clever. It just answers the questions the model would otherwise have to guess: how long, for whom, emphasising what, in what voice, avoiding what.
Giving the model a role can help when it sharpens the task — "You are a technical editor reviewing for clarity" — but only when the role actually changes the behaviour you want. A role with no purpose is just noise.
2. Provide the relevant context
Models can't read your mind or your files. If the task depends on specific information, include it. If you want a reply in your company's style, show a sample of that style. If there are constraints — a word limit, a banned phrase, a required disclaimer — state them explicitly.
A useful habit: before sending, ask yourself "what does this task assume that I haven't told it?" That question surfaces the missing context almost every time.
3. Show, don't just tell (few-shot examples)
For anything with a specific format or style, examples beat description. Instead of describing the output you want, demonstrate it:
Classify the sentiment as positive, negative, or neutral.
Review: "Arrived late and the box was crushed."
Sentiment: negative
Review: "Does the job, nothing special."
Sentiment: neutral
Review: "Honestly exceeded my expectations."
Sentiment:
Two or three good examples often outperform a paragraph of instructions, because they pin down edge cases and format in a way prose struggles to.
4. Specify the output format
If you need structured output — a list, a table, JSON, a specific number of items — say so explicitly, and show the shape. "Return exactly three bullet points, each under 15 words" gets you exactly that. "Respond only with valid JSON matching this structure: {...}" gets you something you can parse. Vague requests get vague shapes back.
5. For reasoning tasks, ask for steps
When a task involves logic, calculation or multi-step analysis, asking the model to work through it step by step before giving a final answer usually improves accuracy. The reasoning becomes visible, which also makes errors easier to catch. "Think through this step by step, then give your final answer" is a small phrase with an outsized effect on harder problems.
6. Iterate like an engineer
The biggest mindset shift: treat prompts as artefacts you refine, not one-shot wishes. The disciplined loop is:
- Write a clear first attempt.
- Test it on several realistic inputs, not one.
- Note where it failed — wrong format, missed a constraint, wrong tone.
- Change one thing.
- Re-test.
- Keep what works; build a small library of prompts that reliably do.
Changing one variable at a time is the same discipline as debugging code, and for the same reason: if you change three things and it improves, you don't know which one mattered.
A quick mental checklist
Before you send any non-trivial prompt, run through five questions:
- Task — is what I want unambiguous?
- Context — have I included everything it needs to know?
- Examples — would a sample make the format or style clearer?
- Format — have I specified the shape of the output?
- Constraints — have I stated the limits and the must-nots?
Master those five and you'll outperform almost everyone hunting for magic words — because there aren't any. There's just clear communication, applied consistently.
Ask Relay — he reads every question himself and replies personally by email.
