01 · Introduction
What a prompt is
A prompt is the text you give a language model. Your question, plus any instructions, examples and documents you add. The model reads it all and writes a reply.
There is no magic in the word. A prompt can be two words ("translate this") or twenty pages (a contract plus a checklist). What matters is whether it contains what the model needs to do the job.
Most tools split a prompt into two parts:
- System prompt: standing instructions that apply to the whole conversation. "You are a support assistant for a bike shop. Answer in Dutch. Never promise a refund." Apps and agents usually hide this part from the end user.
- User message: the thing you want right now. "Reply to this email."
Prompt engineering just means writing prompts on purpose, testing them, and keeping the ones that work.
02 · When to use it
When the prompt is the problem
If the model's answer is wrong or useless, the prompt is the first thing to check. Typical signs:
- The answer is generic. You did not say who it is for or what it is about.
- The format is wrong. You did not say "a table" or "three bullet points" or "JSON".
- It made something up. The facts were not in the prompt, so it guessed.
- It did too much. You asked for "help with this" instead of "fix the second paragraph".
- It works for you but not for a colleague. The prompt relied on things only you knew.
A good prompt is also what makes an automation reliable. In a workflow or an agent, the same prompt runs thousands of times, so one clear sentence saves a thousand bad outputs.
03 · Setup
A simple recipe
Give the model the same things you would give a new colleague:
- Role and audience. "You are helping a sales manager prepare for a client call."
- The task, in one sentence. "Summarize the attached meeting notes."
- The material. Paste the notes. Put long material inside clear markers such as
<notes> ... </notes>so the model knows where it starts and ends. - The shape of the answer. "Five bullet points, each under 20 words, plain language."
- Rules. "If a decision is unclear, say so instead of guessing."
- One example when the format matters, such as the exact layout of a report.
Put instructions before the material, and the question at the end. Then run it, look at the answer, and change one thing at a time.
04 · How to use it
Day-to-day use
- Be specific about what "good" looks like. "Professional but warm, no exclamation marks" beats "nice tone".
- Say what to do, not only what to avoid. Models follow positive instructions better.
- Ask for the answer in a fixed format when another step will read it, such as a table or JSON with named fields.
- When the task is hard, let the model think first: "Work through the problem step by step, then give the final answer."
- Save prompts that work in a file you can reuse. In Claude Code and similar tools, that file is a skill.
- For automations, keep a few test inputs and run them again after every prompt change.
05 · Pitfalls
Pitfalls
- Prompt injection. If your prompt includes text from outside (an email, a web page), that text can contain instructions too. Tell the model which part is data, and never let it act on instructions found inside the data.
- Secrets in prompts. Everything you paste goes to the provider. Keep passwords, keys and personal data out.
- Too long. A ten-page prompt costs more and gives the model more places to get confused. Send what the task needs.
- Model updates. A prompt tuned for one model may need adjustment on the next. Keep the tests.
- Magic phrases. "Act as a world-class expert" changes little. Clear instructions and good material change a lot.
06 · Resources
Where to go next
A prompt is one request. Context is the limit on how much fits in it, and caching is how a long, repeated prompt stays cheap.