Prompt engineering techniques: 9 ways to write better LLM prompts

Key takeaways

• Prompt engineering is the practice of writing instructions that make a large language model such as ChatGPT, Claude or Gemini produce the output you actually need, reliably.
• The official guides from OpenAI, Anthropic and Google agree on a core set of techniques: clear and specific instructions, context about why, a few good examples, clear structure, and a defined output format.
• Anthropic's guide recommends 3–5 examples; Google's says to "always include few-shot examples"; OpenAI advises showing "a diverse range of possible inputs".
• For long documents, put the material first and the question last. Anthropic reports that queries at the end can improve response quality "by up to 30 percent" in its tests.
• Do not judge a prompt from one good answer. Test variants against a small labelled evaluation set, which takes about 40 lines of Python (included below).

What is prompt engineering, and why does it still matter?

The core prompt engineering techniques are the ones OpenAI, Anthropic and Google agree on: clear, specific instructions, context about why, a few good examples, clear structure and a defined output format. They apply whether you use ChatGPT, Claude, Gemini or a local model.

Newer models are better at guessing what you mean, but guessing is the problem. A model that fills gaps with assumptions gives you a different answer every time you rephrase. Anthropic's documentation puts it this way: think of the model as "a brilliant but new employee who lacks context on your norms and workflows." The more precisely you explain the task, the better the result.

This guide is vendor-neutral. Each technique below comes with a before-and-after example and a pointer to the official documentation it is based on. At the end you will find a short Python script for testing prompt variants against your own examples. To check whether a prompt change really helps, build a small golden test set as shown in how to evaluate an LLM app in Python.

Before you start: define what "good" looks like

Anthropic's prompt engineering overview says you need three things before you start tuning: a clear definition of success criteria, a way to test against those criteria, and a first draft of the prompt. That order matters. Without a test, you are only comparing impressions.

Anthropic's evaluation guide describes good success criteria as specific, measurable, achievable and relevant. "Good summaries" is not a criterion. "Summaries under 80 words that mention every deadline in the source email" is one, because a script or a reviewer can check it.

The core techniques at a glance

The table maps the main techniques to what each vendor's official guide says about them. Wording is paraphrased unless shown in quotation marks.

Sources: OpenAI API documentation, Anthropic Claude documentation and Google Gemini API documentation, accessed 22 October 2026 (links in Sources below).

1. Write clear, specific instructions

The most common cause of a weak answer is an underspecified request. State the task, the audience, the length, the format and anything the model should not do. Anthropic suggests a simple test: show the prompt to a colleague with no context. If they would be confused, the model will be too.

Before:

Summarize this email.

After:

Summarize the email below for a project manager who has 30 seconds to read it. Use at most 3 bullet points. List every deadline with its date. If the email asks the reader to do something, start the first bullet with "Action:". Do not include greetings or signatures.

Use numbered steps when order matters. If you want the model to go beyond the minimum, say so explicitly rather than hoping it will infer it.

2. Explain why, not just what

Instructions work better when the model understands the reason behind them. Anthropic's guide gives a neat example: instead of "NEVER use ellipses", explain that the response will be read aloud by a text-to-speech engine that cannot pronounce them. The model can then apply the same logic to cases you did not list, such as avoiding emoji or tables.

A short line of context ("this list will be pasted into a spreadsheet", "the readers are non-technical customers") often fixes more problems than a long list of rules.

3. Use roles and system prompts for stable behaviour

Most chat APIs separate stable rules from per-request input. OpenAI's documentation describes developer messages as providing "the system's rules and business logic", while user messages carry the end user's input. Anthropic recommends setting a role in the system prompt, noting that "even a single sentence makes a difference". Its own example is a system prompt that reads "You are a helpful coding assistant specializing in Python."

A practical layout for a system or developer prompt, following OpenAI's suggested sections, is:

1. Identity: who the assistant is and who it serves.
2. Instructions: rules, constraints and the output format.
3. Examples: a few input-output pairs.
4. Context: reference material the model should use.

Keep user-supplied text out of the system prompt. That separation makes it easier to reason about which instructions the model should prioritise, and it is a basic defence when the input may contain text that tries to override your rules.

4. Show, don't tell: few-shot examples

Examples are the fastest way to fix tone and format. All three vendors recommend them. Google's Gemini guide goes furthest, recommending few-shot examples in every prompt, while warning that too many can make the model overfit to them. Anthropic suggests 3–5 examples that are relevant to the real task and diverse enough that the model does not copy accidental patterns.

Before (zero-shot):

Classify this support ticket as billing, bug or feature request.

After (few-shot, with tags):

Classify the support ticket into exactly one label: billing, bug, feature_request.
Reply with the label only.

<examples>
<example>
<ticket>I was charged twice for October.</ticket>
<label>billing</label>
</example>
<example>
<ticket>The export button does nothing in Firefox.</ticket>
<label>bug</label>
</example>
<example>
<ticket>Could you add dark mode to the mobile app?</ticket>
<label>feature_request</label>
</example>
</examples>

<ticket>{ticket}</ticket>

Keep the formatting of every example identical. If one example uses a different label spelling, expect the model to copy it sometimes.

5. Structure the prompt with tags or headings

When a prompt mixes instructions, documents, examples and user input, delimiters stop the model from confusing one for another. Anthropic recommends XML tags such as <instructions> and <context>; OpenAI's guide says Markdown headers and XML tags both help; Google's guidance for its Gemini 3 models asks for consistent delimiters of either kind.

For long inputs, order matters. Anthropic advises placing long documents at the top, above the query and instructions, for inputs of roughly 20,000 tokens or more, and wrapping each document in its own tag with its source. Google gives the same advice for long contexts: data first, instructions last.

<documents>
  <document index="1">
    <source>q3-report.pdf</source>
    <document_content>...</document_content>
  </document>
</documents>

Using only the documents above, list the three largest cost increases
in Q3 and quote the sentence that supports each one.

6. Ask for reasoning on hard problems

For multi-step problems such as maths, planning or analysis across several documents, asking the model to reason before answering usually helps. How you ask has changed. Many current models, including OpenAI's reasoning models and Claude models with extended or adaptive thinking, reason internally when the feature is enabled. OpenAI notes that reasoning models often do well with high-level goals rather than detailed step lists, and Anthropic says a general instruction such as "think thoroughly" often beats a hand-written step-by-step plan.

When thinking features are off, or you are using a smaller model, a plain instruction still works: "Work through the problem step by step inside <reasoning> tags, then give the final answer inside <answer> tags." Separating the two lets your code show only the answer to users.

7. Get structured output you can parse

If code will read the answer, ask for a machine-readable format and validate it. A prompt can request JSON, but the strongest option is the platform's schema feature. OpenAI's documentation explains the difference: "While both ensure valid JSON is produced, only Structured Outputs ensure schema adherence." Anthropic's documentation describes a structured outputs feature for Claude that is "designed specifically to constrain Claude's responses to follow a given schema".

One older trick is fading out. Developers used to "prefill" the start of Claude's reply (for example with an opening brace) to force JSON. Anthropic's documentation says prefilled responses on the last assistant turn are no longer supported starting with Claude 4.6 models, and points to structured outputs, tool calling or direct instructions instead. Google's guide still describes starting the output yourself as a completion strategy for Gemini, so check the current docs for your model.

For classification, Anthropic suggests a tool or schema with an enum field listing the valid labels, so the model cannot invent a new one.

8. Chain prompts instead of writing one giant prompt

A single prompt that researches, drafts, checks facts and formats will do each job less well than a chain of smaller prompts. Google's guide recommends splitting complex work into one prompt per instruction, chaining sequential steps or running parallel tasks and combining the results. Anthropic describes the most common chain as self-correction: generate a draft, have the model review it against criteria, then refine it, with each step as a separate API call you can log and evaluate.

1. Extract: pull the relevant facts from the source into JSON.
2. Draft: write the answer using only that JSON.
3. Review: check the draft against a checklist and list problems.
4. Revise: fix the listed problems.

Chaining also pairs well with retrieval. If your prompt needs fresh or private data, see our guide on building a RAG app in Python.

9. Test prompt variants against a small evaluation set

A prompt that works on the one example you tried may fail on the next ten. Anthropic's evaluation guide recommends automating grading where possible and prioritising volume, stating that more test questions with slightly lower-signal automated grading is better than a few hand-graded ones. OpenAI recommends building evals and pinning production apps to specific model snapshots so behaviour does not shift under you.

The script below compares two prompt variants on a labelled set using exact-match scoring. It uses the openai Python package against any OpenAI-compatible endpoint, so it works with OpenAI or with a local model served by Ollama (see how to run a local LLM with Ollama).

# pip install openai
import os
from openai import OpenAI

# Local Ollama: base_url="http://localhost:11434/v1", api_key="ollama"
client = OpenAI(
    base_url=os.environ.get("BASE_URL", "http://localhost:11434/v1"),
    api_key=os.environ.get("API_KEY", "ollama"),
)
MODEL = os.environ.get("MODEL", "llama3.2")
LABELS = {"billing", "bug", "feature_request"}

PROMPTS = {
    "v1_plain": "Classify this support ticket as billing, bug or feature request.",
    "v2_rules": (
        "Classify the support ticket into exactly one label: "
        "billing, bug, feature_request. Reply with the label only, lowercase."
    ),
}

EVAL_SET = [
    ("I was charged twice this month.", "billing"),
    ("App crashes when I upload a PNG.", "bug"),
    ("Please add CSV export to reports.", "feature_request"),
    ("My invoice shows the wrong VAT number.", "billing"),
    ("Login page shows a blank screen on Safari.", "bug"),
    ("It would be great to schedule posts in advance.", "feature_request"),
]

def classify(system_prompt, ticket):
    resp = client.chat.completions.create(
        model=MODEL,
        temperature=0,
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": ticket},
        ],
    )
    return resp.choices[0].message.content.strip().lower()

for name, prompt in PROMPTS.items():
    correct, invalid = 0, 0
    for ticket, expected in EVAL_SET:
        answer = classify(prompt, ticket)
        if answer not in LABELS:
            invalid += 1
        if answer == expected:
            correct += 1
    print(f"{name}: {correct}/{len(EVAL_SET)} correct, {invalid} invalid labels")

Six cases are only a starting point. Grow the set to a few dozen, add edge cases (empty tickets, tickets in another language, tickets that fit two labels) and rerun it every time you change the prompt or the model. Note that some newer models ignore the temperature setting; Google's guide says this of its latest Gemini models, so do not rely on it alone for consistency.

For free-text outputs where exact match does not work, Anthropic's guide lists alternatives: code-based checks (length, required keywords), similarity scores, and LLM-based grading with a clear rubric, ideally using a different model from the one being tested.

Common prompt mistakes to avoid

• Vague goals: "make it better" gives the model nothing to aim at. Name the reader, length and format.
• Rules without reasons: a bare "NEVER" in capitals is less useful than one sentence explaining why.
• Inconsistent examples: mixed formats in examples produce mixed formats in answers.
• Mixing data and instructions: untagged documents and user input can be read as instructions.
• Judging by one output: results vary between runs; only a test set tells you whether a change helped.
• Copying model-specific tricks blindly: techniques such as prefill or temperature tuning depend on the model and version.

What it means for builders and everyday users

The striking point across the three official guides is how much they agree. Clear instructions, context, examples, structure and testing work for ChatGPT, Claude and Gemini alike. Model-specific advice exists, mostly around reasoning settings, prefill and sampling parameters, but it sits on top of the same foundation.

For everyday users, the biggest gains come from the first four techniques: say exactly what you want, explain why, show an example and separate your material from your request. For developers, the habit that matters most is treating prompts like code: version them, test them against a fixed set of cases and pin the model version in production.

Prompt engineering is also the first step before heavier options. If prompting and retrieval are not enough, you can move on to fine-tuning an LLM with LoRA, give the model tools with a tool-calling agent in Python, or connect it to your own systems through an MCP server.

Sources

• Anthropic: Prompt engineering overview
• Anthropic: Prompting best practices
• Anthropic: Define success criteria and build evaluations
• OpenAI: Prompt engineering guide
• OpenAI: Structured model outputs
• Google: Gemini API prompting strategies