How to Write Better AI Prompts: A Practical Framework
Key Takeaways
- A good prompt has five parts: role, task, context, format and constraints. Missing any one of them is the most common reason for a vague answer.
- Structure beats length. A clear three-line prompt usually outperforms a vague thirty-line one.
- Show the model an example of the output you want when format matters; one example often does more than a paragraph of description.
- Iterate on one change at a time: fix the specific thing wrong with the last answer, rather than rewriting the whole prompt and losing what worked.
- The examples in this article are invented example tasks, labelled as such, not real client work.
Most bad AI answers are not model failures. They are specification failures. The model can only work with what you gave it, and if you gave it a vague goal, no context, no format and no constraints, a vague answer is the correct response to that prompt. Prompt engineering is the discipline of writing a specification the model can actually follow — and it is a learnable skill, not a collection of magic phrases.
The framework: role, task, context, format, constraints
Every prompt that works reliably contains the same five parts, even when they are only a sentence each. Microsoft’s prompt engineering guidance describes the same pattern as instruction plus context plus output, and most guides converge on a similar shape. Here is the version used in this article.
| Part | What it answers | Example |
|---|---|---|
| Role | Who should the model act as? | “You are a patient maths tutor for a 14-year-old.” |
| Task | What exactly should it do? | “Explain why we divide by a fraction.” |
| Context | What background does it need? | “The student knows multiplication but not division of fractions.” |
| Format | What should the output look like? | “Three short paragraphs, then one worked example, no bullet list.” |
| Constraints | What must it not do? | “Under 200 words. No jargon without a plain explanation.” |
Role is the cheapest improvement available. It loads relevant conventions: a tutor explains step by step, an editor flags problems, a project manager talks about owners and deadlines. Context is where most prompts fail, because the writer knows the background and forgets the model does not. Format is where most outputs become unusable, because without it the model guesses a shape you did not want. Constraints are where quality lives: length, tone, banned words, and what to do when information is missing.
Before and after: the same task, two prompts
Here is an invented example task, used only to show the difference. The task: write a product description for a fictional reusable water bottle.
Before: the vague prompt
“Write a product description for a water bottle.”
This prompt gives the model nothing to work with. Who is it for? What makes this bottle different? How long should it be? What tone? The model will invent answers to all of those questions, and the result will read like every other bottle description on the internet, because it is assembled from the average of all of them.
After: the specified prompt
“You are a copywriter for an outdoor shop. Write a product description for a fictional 750ml stainless steel water bottle that keeps drinks cold for 24 hours and fits a bicycle bottle cage. The reader is a commuter cyclist. Format: one headline under 10 words, then two paragraphs, then three bullet points of specifications. Constraints: under 150 words, plain language, no superlatives like ‘best’ or ‘revolutionary’, and do not invent a price.”
Every part of the framework is present, and the model has nothing left to invent except the wording itself. Notice the last constraint: “do not invent a price”. When information is missing, a good prompt says what to do about the gap — omit it, mark it, or ask — instead of letting the model fill it silently. That single habit prevents most of the confident fiction AI tools produce.
A second before-and-after: explaining a technical idea
Invented example task: explain how a password manager works to a non-technical reader.
Before: “Explain password managers.” The result will likely be a generic definition, possibly too technical, possibly too long, with no sense of what the reader actually worries about.
After: “You are a friendly technology writer. Explain how a password manager works to a reader who reuses the same password everywhere and is worried about being hacked. Context: the reader uses a phone and a laptop, no technical background. Format: start with the one-sentence idea, then a short analogy, then three steps to get started. Constraints: under 250 words, no jargon without a plain explanation, end with the one thing to do today.”
The after version works because it names the reader’s actual fear (being hacked after reusing passwords) and the actual next step (the one thing to do today). Good prompts are written from the reader’s situation, not from the topic’s definition.
Common failures, and the fix for each
| Failure | What it looks like | Fix |
|---|---|---|
| Vague goal | “Write about AI.” | Name one task, one reader, one outcome. |
| No output format | A wall of text when you wanted a table. | State the format: table, bullets, headings, word count. |
| No constraints | Superlatives, invented facts, wrong length. | Ban the specific failure: “no invented prices”, “under 200 words”. |
| Buried constraints | A rule hidden in a long paragraph, ignored. | Put constraints in a separate bulleted list, not inside prose. |
| Multiple unrelated tasks | One prompt asking for a summary, a translation and a critique. | Split into separate prompts; one task per prompt. |
| Accepting the first answer | Publishing or using output you have not read critically. | Treat the first answer as a draft; iterate on what is wrong. |
Two failures deserve emphasis. First, few-shot examples: when format matters, showing one example of the output you want usually outperforms describing the format at length. Models are pattern matchers; give them the pattern. Second, iteration discipline: when an answer is wrong, change one thing — add a constraint, add an example, narrow the task — and see what changes. Rewriting the whole prompt after every failure destroys the evidence about which change helped.
A short checklist to use before you send a prompt
- Does the prompt name a role?
- Does it state exactly one task?
- Does it include the context the model cannot guess?
- Does it specify the output format, including length?
- Does it list constraints, including what to do when information is missing?
- Does it include an example, if format matters?
- Would a competent human understand this prompt without asking a clarifying question? If not, the model will guess, and the guess will be confident.
That last question is the whole test. Prompt engineering is not about learning the model’s secret language. It is about writing instructions clearly enough that a stranger could follow them, because that is, in effect, what you are asking the model to do.
For a beginner-friendly starting point, see AI tutorials for beginners and an honest beginner’s guide to learning AI. For what agents do with prompts once they start calling tools, see what AI agents are and how they work.
Limitations
The examples in this article are invented for illustration and have not been run as a controlled experiment; prompt behaviour varies by model, version and task, and a technique that helps on one model may matter less on another. This article describes widely used guidance from the sources below, not a tested ranking of prompting techniques. Treat the framework as a starting discipline, and measure what works on your own tasks.
