How to Write a Good AI Prompt (With Before and After Examples)

A good prompt tells the model what to do, why, for whom, under which constraints and in what format, and shows an example when the format matters. OpenAI and Anthropic both summarise it the same way: be specific, give the context a new colleague would need, and show rather than describe the output you want.

Anthropic's guide offers a test worth using on every prompt: show it to a colleague who knows nothing about the task and ask them to follow it. "If they'd be confused, Claude will be too." The same applies to any model.

The five parts of a good prompt

OpenAI's prompt engineering guide recommends structuring a longer prompt as identity, instructions, examples and context. Anthropic's guide covers the same ground under different headings. Merged, they come to five parts. Not every prompt needs all five, but when a result disappoints, one of them is usually missing.

In an API, the role and standing rules normally go in the system or developer message and the specific task in the user message. System prompt vs user prompt explains the split.

Before and after: four prompts rewritten

The prompts below are our own examples, written to apply the guidance from the two guides. Each "after" version adds the parts the "before" version leaves out.

1. Summarising a document

Before:

Summarize this report.

After:

<report>
{{REPORT_TEXT}}
</report>

I'm a project manager presenting this report to our finance director tomorrow.
She cares about cost overruns and schedule risk, not technical detail.

Summarize the report in 5 bullet points, most important first, each under 25 words.
Then add one line starting "Decision needed:" if the report asks for a decision.
If the report does not mention costs, say so instead of guessing.

What changed: the audience and purpose (context), a length and order (constraints), an exact structure (format), and permission to say information is missing. Anthropic's long-context guidance also recommends putting long documents at the top and the question at the end; its docs report that queries at the end can improve response quality by up to 30 percent in their tests with complex, multi-document inputs.

2. Writing code

Before:

Write a function to validate email addresses.

After:

Write a Python 3.12 function `is_valid_email(address: str) -> bool` for a signup form.

Requirements:
- Reject empty strings, missing "@", and addresses with spaces.
- Accept plus addressing ([email protected]).
- Do not try to implement the full RFC 5322 grammar; a practical check is enough,
  because we confirm addresses by sending a verification link anyway.
- Standard library only.

Return the function, then 6 pytest test cases covering the rules above.

The reason given in the third requirement matters. Anthropic's guide recommends explaining why a constraint exists, because the model can generalise from the explanation. Its own example contrasts "NEVER use ellipses" with a version that explains the text will be read aloud by a text-to-speech engine that cannot pronounce them.

3. Classifying data (show, don't describe)

Before:

Categorize these support tickets by type.

After:

Classify each support ticket into exactly one category:
billing, bug, feature_request, account_access, other.
Reply with one line per ticket: ticket_id,category

<examples>
<example>
Ticket 101: "I was charged twice this month."
101,billing
</example>
<example>
Ticket 102: "Can you add dark mode?"
102,feature_request
</example>
<example>
Ticket 103: "The export button does nothing in Firefox."
103,bug
</example>
</examples>

<tickets>
{{TICKETS}}
</tickets>

Both guides call examples one of the most reliable ways to control output. OpenAI's guide describes few-shot prompting as steering the model with input/output examples instead of fine-tuning, and advises showing "a diverse range of possible inputs". Anthropic's guide recommends 3 to 5 examples, made relevant to the real task and varied enough that the model does not copy an accidental pattern, wrapped in <example> tags so they are not mistaken for instructions.

4. Controlling the format

Before:

Explain how DNS works. Don't use bullet points or headers.

After:

Explain how DNS resolves a domain name to an IP address, for a reader who knows
what a browser and a server are but nothing about networking.
Write it as three short paragraphs of plain prose, about 200 words in total.

Anthropic's guide advises telling the model what to do instead of what not to do. Its example replaces "Do not use markdown in your response" with "Your response should be composed of smoothly flowing prose paragraphs." The guide also notes that the style of your prompt influences the style of the answer, so a prompt full of Markdown tends to get Markdown back.

Use tags or headings to separate parts

When a prompt contains instructions, reference material and examples, mark where each begins and ends. OpenAI's guide suggests Markdown headings and lists for sections and XML tags for content boundaries, such as a pasted document. Anthropic's guide recommends consistent, descriptive tag names (<instructions>, <context>, <input>) and nesting for multiple documents (<documents> containing several <document index="n"> blocks). The tag names themselves are not special; consistency is what helps.

Ask for steps when order matters

If the task has a sequence, or every item must be covered, write it as a numbered list. Anthropic's guide recommends sequential steps "when the order or completeness of steps matters". For example: "1. Extract every date from the contract. 2. For each date, quote the clause it appears in. 3. Flag any date earlier than today." This also makes it easier to see which step went wrong when the output is off.

Let the model say it does not know

Models tend to produce an answer even when the information is not there. A single sentence such as "If the document does not contain the answer, say so" gives the model an alternative to guessing. Anthropic's hallucination guide says explicitly permitting uncertainty "can drastically reduce false information". More techniques are in why AI hallucinates and how to reduce it.

Test prompts like code

A prompt that works once may not work on the next ten inputs. OpenAI's guide recommends building a small set of test inputs and evaluations so you can tell whether a change helped, and pinning a model snapshot so behaviour does not shift under you. A practical routine:

• Collect 10 to 20 real inputs, including awkward ones (empty, very long, off-topic).
• Run the old and new prompt on all of them.
• Compare the outputs side by side. A text diff makes small wording changes easy to spot; larely's diff checker works in the browser.
• Change one thing at a time, so you know which edit made the difference.

If the output is still wrong

Read your prompt as if you had never seen the task. Usually the model did what the words said, and the words left something out: the audience, the length, what to do with missing data, or what "good" looks like. Add that, or add an example of the output you expected, before trying a bigger model. For reasoning models, OpenAI's guide suggests the opposite adjustment as well: give the goal and constraints, and avoid micromanaging every step, since those models "provide better results on tasks with only high-level guidance."

Frequently asked questions

How long should a prompt be?

As long as it needs to be for someone without your context to do the task correctly, and no longer. A one-line prompt is fine for a simple, well-known task. A task with specific constraints, a particular audience or a required format needs those spelled out, which usually means a paragraph or more. Extra length that does not add information costs tokens and can distract the model.

Where should a long document go in the prompt?

The vendors' advice differs slightly. Anthropic's guide says to put long documents near the top, above the question and instructions, and reports that queries at the end improved response quality by up to 30 percent in its tests. OpenAI's guide says supporting context is usually best placed near the end of the prompt, after the instructions. Follow the guide for the model you use, and test both if it matters.

Should I write prompts in Markdown or XML?

Either works as long as the structure is clear. OpenAI's guide suggests Markdown headings and lists to mark sections and XML tags to show where a piece of content starts and ends. Anthropic's guide recommends XML tags such as <instructions> and <document> when a prompt mixes instructions, context and examples.

Do the same prompts work on every model?

Mostly, but not exactly. OpenAI's guide notes that reasoning models do better with high-level goals, while non-reasoning GPT models need more explicit step-by-step instructions, and it recommends pinning a model snapshot and keeping test cases so you notice when an upgrade changes behaviour.

Sources

• Claude API docs: Prompting best practices
• OpenAI API docs: Prompt engineering
• Claude API docs: Reduce hallucinations