Prompt engineering basics: nine techniques from OpenAI's and Anthropic's documentation

Prompt engineering is the process of writing effective instructions for a model so that it consistently produces the output you need. OpenAI's documentation defines it in almost those words, and adds that because model output is not deterministic, getting what you want is "a mix of art and science". This guide gathers the techniques that OpenAI and Anthropic both document for their current models, checked on October 6, 2026, and shows how to apply them with before-and-after examples of our own. It works with any chat assistant or API, and it is not a collection of magic phrases: the techniques are about being clear, giving context and testing what you write.

What to do before you write the prompt

Anthropic's guide starts with three things you need first: a clear definition of the success criteria for your use case, some way to test against those criteria, and a first draft of the prompt. If you do not have them, it points to defining success criteria and building evaluations before tuning wording. OpenAI says the same in other words: build tests and evaluation suites that measure prompt behavior, so that you can monitor results as you iterate or when you change model versions, and pin production applications to a specific model snapshot so behavior stays consistent.

Anthropic also reminds readers that not every failing evaluation is best solved by editing the prompt: sometimes you can improve latency and cost more easily by choosing a different model. For the prices behind that choice, see LLM API pricing compared.

1. Be clear and direct

Anthropic's first principle is that Claude responds well to clear, explicit instructions, and that if you want "above and beyond" behavior you should ask for it instead of expecting the model to infer it. Its rule of thumb is to treat the model as "a brilliant but new employee who lacks context on your norms and workflows", and its golden rule is to show your prompt to a colleague with minimal context and ask them to follow it: if they would be confused, the model will be too. Be specific about the output you want and, when order matters, give the steps as a numbered list.

Anthropic's own example: "Create an analytics dashboard" is less effective than "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation."

2. Give the reason behind an instruction

Explaining why you want something helps the model apply it sensibly. In Anthropic's example, "Never use ellipses" is less effective than "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." The model can generalize from the reason to cases you did not list.

3. Use roles and levels of authority

OpenAI separates instructions by who gives them: developer messages come from the application developer and are prioritized ahead of user messages, which come from the end user. It suggests thinking of the developer message as a function definition, with the rules and business logic, and the user message as the arguments. Anthropic makes the same point with the system prompt: setting a role there, even in a single sentence such as "You are a helpful coding assistant specializing in Python", focuses the model's behavior and tone. In a chat app without those settings, the equivalent is to open with who the assistant should be and what you want done.

4. Structure the prompt

OpenAI says a developer message usually contains four sections, in this order: identity (purpose and style), instructions (rules, what to do and not to do), examples, and context (extra information such as private data), with the context best placed near the end because it changes between requests. Markdown headers and lists mark sections; XML tags mark where one piece of content, such as a reference document, begins and ends. Anthropic recommends XML tags too, with consistent and descriptive names, because they help the model parse a prompt that mixes instructions, context, examples and inputs without ambiguity.

5. Show examples

Examples are, in Anthropic's words, one of the most reliable ways to steer format, tone and structure. A few well-chosen examples (few-shot or multishot prompting) improve accuracy and consistency. Anthropic says to make them relevant to your real use case, diverse enough to cover edge cases so the model does not pick up unintended patterns, and structured in tags so they cannot be confused with instructions; it suggests three to five. OpenAI describes few-shot learning as steering a model toward a task by including a handful of input and output examples instead of fine-tuning it, and advises showing a diverse range of inputs.

6. Put long documents first and the question last

For large inputs, Anthropic advises placing long documents near the top of the prompt, above the query, instructions and examples, and reports that putting the query at the end can improve response quality by up to 30 percent in its tests, especially with complex, multi-document inputs. For tasks over long documents, it also suggests asking the model to quote the relevant parts first. Google's long-context guide gives the same advice about placing the question after the context. If you reuse the same instructions across many requests, keep the stable part at the beginning: OpenAI notes this also maximizes the savings from prompt caching.

7. Say what to do, not what not to do

Anthropic lists this as an effective way to control format: instead of "Do not use markdown in your response", write "Your response should be composed of smoothly flowing prose paragraphs." Positive instructions give the model a target; prohibitions leave it guessing what to do instead.

8. Specify the output format

State the format you need: length, structure, language, sections. When software will read the answer, use the structured output features of your API so that the response follows a JSON schema; OpenAI notes that models can return structured data in JSON format through its Structured Outputs feature. For long documents, tell the model whether you want a summary, a table or a list, and in what order.

9. Test it, version it and re-test it

Prompts are code. OpenAI recommends storing production prompts in your application code, with typed inputs, review and tests, and adding representative cases and evaluation checks before you change a prompt that is live. Different model types (reasoning models and GPT models) can need different prompting, and even different snapshots in the same family can behave differently, so re-run your evaluations when you change model. Our guides to Claude vs ChatGPT and ChatGPT pricing explain which models each plan gives you.

A worked example

This is our own example of the techniques together, for a customer-support assistant. The weak version is "Answer customer questions about our returns." The stronger version uses the sections OpenAI describes:

• Identity: "You are the support assistant for a small online shop. You write short, friendly answers in the customer's language."
• Instructions: "Answer only from the policy in the context. If the policy does not cover the question, say you will pass it to a person. Give the answer first, then the steps, as a numbered list. Do not promise refunds."
• Examples: two or three sample questions with the answers you would want, wrapped in example tags.
• Context: the returns policy text, placed last, followed by the customer's message.

Then run it on 30 to 50 real past questions and read the answers before any customer sees it. If the model lacks information, adding the right documents (retrieval) will do more than rewording: see what RAG is.

What prompting cannot fix

A better prompt does not make a model know what it was not given, and it does not guarantee a correct answer. For facts that change or are private, give the model the source text. For decisions that matter, keep a person in the loop and check the result. For a model that is too slow or too expensive, try a different model before a longer prompt. Models can also state false things fluently, and our guide to model hallucinations explains why and which prompt techniques reduce it, such as allowing the model to say it does not know.