How to Write AI Prompts That Get Reliable Results: A Practical Framework
Most advice on how to write AI prompts stops at "be specific". That's true, but it doesn't tell you what to be specific about, or how to tell whether a prompt works. This guide gives you a six-part framework drawn from the model makers' own documentation, plus a short testing routine, so the prompt you write once keeps working the tenth time you use it.
A chat assistant can give you a brilliant answer on Tuesday and a sloppy one on Wednesday from almost the same request. That inconsistency is the real problem for anyone using AI at work. A lucky one-off is easy. A prompt you can hand to a colleague, or reuse every week on new material, is harder.
The good news is that the companies building these models have published fairly consistent advice. OpenAI's prompt engineering guide, Anthropic's prompting best practices and Google's prompt design strategies for Gemini differ in detail, but they agree on the fundamentals. The framework below organises those fundamentals into something you can use from memory.
Start with the answer, not the prompt
Before you type anything, write down what a good result looks like. Anthropic's documentation says its prompt guidance assumes you already have clear success criteria and a way to test against them. OpenAI similarly recommends building evals, small test suites that measure how a prompt behaves, so you notice when a change makes things worse.
For everyday use that can be three lines in a notebook:
- Must: under 120 words, mentions the delivery date, polite but firm.
- Must not: promise a refund, invent order details.
- Nice to have: ends with one clear next step for the customer.
Those criteria do double duty. They become the constraints inside your prompt, and they become the checklist you mark each answer against.
The six-part prompt framework
Think of a prompt as a briefing for a capable new colleague who knows nothing about your situation. Anthropic puts it as a "golden rule": show your prompt to a colleague with minimal context and ask them to follow it. If they'd be confused, the model will be too. A good briefing covers six things.
| Part | What it answers | Weak version | Stronger version |
|---|---|---|---|
| 1. Goal | What is this for, and who reads it? | "Summarise this." | "Summarise this call for a sales manager deciding whether to follow up this week." |
| 2. Context | What background would a newcomer need? | (none) | "We sell accounting software to small firms in India. Pricing questions go to finance, not sales." |
| 3. Input | What material should be used, clearly marked? | Text pasted straight after the request | Text wrapped in <transcript> tags |
| 4. Constraints | Limits, tone, things to avoid | "Keep it short." | "Maximum five bullet points. Don't speculate about the customer's budget." |
| 5. Output format | Exactly what shape the answer takes | (none) | "Return: Decision, Reasons (3 bullets), Next step." |
| 6. Examples | What "good" looks like in practice | (none) | One or two short sample outputs |
1. Goal: say what the output is for
A purpose changes what the model chooses to include. Anthropic notes that explaining the reason behind an instruction helps the model deliver more targeted responses. "Never use ellipses" is a rule. "This will be read aloud by a text-to-speech tool, so never use ellipses" is a rule the model can generalise from.
2. Context: give the background a newcomer needs
Models don't know your company, your customers or your house style unless you tell them. Google's guide recommends adding source material and context so answers are specific rather than generic. If you assign a role ("You are a careful compliance reviewer for a mid-sized Indian NBFC"), keep it to a sentence or two. Anthropic says even a single sentence of role-setting makes a difference.
3. Input: fence off the material
When instructions and pasted text run together, the model can't always tell which is which. OpenAI recommends Markdown headings and XML tags to show where reference content begins and ends, and Anthropic advises wrapping each kind of content in its own tag, such as <instructions> and <input>. The tag names don't need to be special. They just need to be consistent.
Where you put long material matters too. A widely cited 2023 study found that models use information at the start or end of a long input more reliably than information buried in the middle. Anthropic's advice is to put long documents near the top and your question at the end, which it says improved response quality by up to 30 per cent in its tests with complex, multi-document inputs. Google gives similar advice for its Gemini 3 models: long context first, instructions after.
4. Constraints: say what to do, not only what to avoid
Length limits, tone, reading level and banned topics all belong here. Phrase them positively where you can. Anthropic's guide recommends telling the model what to do instead of what not to do: "Write in flowing paragraphs" works better than "Don't use bullet points".
5. Output format: describe the shape
If the answer goes into a spreadsheet, an email or another tool, specify the structure exactly: headings, field names, a table, or JSON. Google's guide lists response format as a core part of prompt design. A fixed format also makes answers far easier to compare when you test.
6. Examples: show, don't describe
One good example often beats a paragraph of adjectives. Google goes as far as recommending that you always include a few examples, while warning that too many can make the model copy them too closely. Anthropic suggests three to five varied examples for best results. Make them differ from each other, or the model may reproduce one example's quirks every time.
A prompt is a briefing. If a sharp new colleague would need to ask you a question before starting, the model needs the answer in writing.
A worked example: before and after
Illustrative example. A small online shop wants help replying to customers whose orders are late.
Before:
Write a reply to this customer complaint about a late order.
[customer email pasted here]
This will produce something plausible. It may also apologise five times, promise a refund the shop doesn't offer, or invent a tracking number. Each run will look different.
After:
<goal>
Draft a reply to a customer whose order is late. A team member will
review and send it, so accuracy matters more than polish.
</goal>
<context>
We are a small online homeware shop shipping within India.
Late orders get a new estimated date and a 10% voucher code.
We do not offer refunds for delays unless the order is 14+ days late.
</context>
<order_details>
[order number, original date, new estimated date]
</order_details>
<customer_email>
[paste email here]
</customer_email>
<instructions>
- Under 120 words, warm and direct, British English.
- Apologise once. Give the new date from order_details.
- Mention the voucher. Mention refunds only if the order is 14+ days late.
- If any detail you need is missing, write [CHECK: what is missing]
instead of guessing.
</instructions>
Return only the email text, starting with "Hi [first name],".
The second prompt is longer, but nearly every line removes a decision the model would otherwise make for you. The [CHECK: …] rule is the most important line in it, for reasons covered below.
Make it safe for the model to say "I don't know"
Language models tend to produce a confident answer even when they lack the facts. A 2025 research paper argues this happens partly because training and evaluation reward confident guessing over admitting uncertainty. Your prompt can push in the other direction.
Anthropic's guidance on reducing hallucinations lists three basic techniques:
- Allow uncertainty. Explicitly give the model permission to admit it doesn't know, for example "If the report lacks the information, say so."
- Ground answers in quotes. For long documents, ask the model to extract the relevant word-for-word quotes first, then answer using only those.
- Verify with citations. Ask it to back each claim with a quote from your material and to remove any claim it can't support.
The same page warns that these techniques reduce hallucinations but don't eliminate them. Treat any figure, name, date or legal point in an AI answer as unconfirmed until you've checked it against a source.
Test before you trust: a five-minute routine
One good answer tells you very little. Before you save a prompt as a template or share it with your team, run this quick check.
- Collect five real inputs. Include an easy one, a long one, a messy one and one with key information missing.
- Run the prompt on each, in a fresh chat each time so earlier messages don't influence the result.
- Mark each answer against your must / must-not list from the start. Pass or fail, no "nearly".
- Fix one thing at a time. Change a single instruction, rerun all five, and compare.
- Save the winning version with a date and a note on what you changed. OpenAI recommends versioning production prompts and testing them like code.
Repeat the test when your tool switches to a newer model. Prompts tuned for one model can behave differently on another. OpenAI notes that its reasoning models work better with high-level goals, while its GPT models need more explicit instructions, so a prompt that suits one may need adjusting for the other.
Break big jobs into smaller prompts
When a prompt starts doing five jobs at once (research, analyse, draft, format, translate), quality usually drops. Google's guide suggests breaking complex tasks into a chain of prompts, where each step's output becomes the next step's input.
Illustrative example for a monthly client report:
- Extract the key figures from the spreadsheet export into a fixed table.
- Write three observations about changes since last month, using only that table.
- Draft the client email from the observations, in your house style.
Each step is easy to check on its own, and when something goes wrong you know exactly where.
A copy-ready template
Paste this into a note and fill in the brackets. Delete any section you genuinely don't need.
<goal>
[What this output is for, and who will read or use it]
</goal>
<context>
[Background a capable newcomer would need: business, audience,
rules, house style]
</context>
<input>
[The document, data or text to work from]
</input>
<examples>
[One to three short examples of a good output, varied]
</examples>
<instructions>
- [Length, tone, reading level]
- [What to include, phrased positively]
- [Limits: what must never appear]
- Use only the information in <input>. If something needed is
missing, write [CHECK: …] instead of guessing.
</instructions>
Output format: [exact structure, headings or fields]
Common mistakes and quick fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Generic, could-be-anyone answer | No context or audience | Add who it's for and two lines of background |
| Invented facts or numbers | No permission to say "unknown" | Add a [CHECK] rule and "use only the input" |
| Ignores part of a long document | Key material buried mid-prompt | Put documents first, question last; ask for quotes |
| Format changes every time | Format described loosely | Specify exact headings or fields, and add an example |
| Copies your example too closely | Only one example, or near-identical examples | Add varied examples, or describe what should change |
| Good last month, worse now | Tool moved to a new model | Rerun your five test inputs and adjust |
If you're building prompts into a product rather than a chat window, the same framework applies, with a test set you run on every change. Our guide on building a custom AI SaaS without code covers versioning and evaluation in that setting.
The bottom line
Reliable prompts aren't clever. They're complete. State the goal, give the background, fence off the input, set the limits, describe the format and show an example. Then give the model a way to say it doesn't know, and test the prompt on several real inputs before you depend on it.
Start with one task you repeat every week. Write the success criteria, build the prompt with the template above and run the five-input test. Most people find one or two missing instructions on the first pass, and those are exactly the gaps that caused the inconsistent results.
Frequently asked questions
Do these techniques work in ChatGPT, Claude and Gemini?
Broadly, yes. OpenAI, Anthropic and Google all recommend clear instructions, separated input, a defined output format and examples. The details differ, and each model responds slightly differently, so test your prompt in the tool you'll actually use.
Do I need XML tags, or will headings do?
Either works. What matters is that instructions and pasted material are clearly separated and that you use one style consistently. XML-style tags are handy when you're pasting several documents, because each one gets an unambiguous start and end.
How long should a prompt be?
As long as it needs to be to remove guesswork, and no longer. A one-off question can be a sentence. A reusable template for customer replies may run to 20 or 30 lines. If a line doesn't change the output when you remove it, cut it.
Will a good prompt stop the AI making things up?
It reduces the risk but can't remove it. Allowing the model to say "I don't know", restricting it to your input and asking for supporting quotes all help. Check any fact that matters against a reliable source before you use it.
Should I keep a prompt library?
Yes, if you reuse prompts. Save each template with the date, the model you tested it on and a note on what changed. That record makes it much easier to fix a prompt when results drift.
Sources
- Prompt engineering, OpenAI, 2026.
- Prompting best practices, Anthropic, 2026.
- Prompt engineering overview, Anthropic, 2026.
- Reduce hallucinations, Anthropic, 2026.
- Prompt design strategies, Google AI for Developers, 2026.
- Lost in the Middle: How Language Models Use Long Contexts, Liu et al., Transactions of the Association for Computational Linguistics (arXiv preprint), 2023.
- Why Language Models Hallucinate, Kalai, Nachum, Vempala and Zhang, arXiv, 2025.

