Prompt engineering guide: techniques from Anthropic, OpenAI and Google

Prompt engineering is the practice of writing, testing and refining the instructions you give a language model so it consistently produces the output you need. OpenAI's prompt engineering guide defines it as "the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements."

This guide collects the techniques that Anthropic, OpenAI and Google document in their official prompting guides, shows each one with an example, and notes where current reasoning models change the advice. Everything was checked against the vendors' docs on 26 October 2026.

What should you have before you start prompt engineering?

A way to tell whether a prompt is getting better. Anthropic's prompt engineering overview says its guide assumes you have:

1. A clear definition of the success criteria for your use case
2. Some ways to empirically test against those criteria
3. A first draft prompt you want to improve

OpenAI makes the same point from the production side. Its guide recommends "Pinning your production applications to specific model snapshots" and "Building tests and evaluation suites that measure prompt behavior so you can monitor performance as you iterate, or when you change and upgrade model versions."

OpenAI notes that "Because the content generated from a model is non-deterministic, prompting to get your desired output is a mix of art and science." A handful of saved test inputs turns that art into something you can measure.

Which techniques do Anthropic, OpenAI and Google all recommend?

The three official guides overlap far more than they differ:

How do you write clear, specific instructions?

Say exactly what you want, including format, length and constraints. Anthropic's prompting best practices puts it this way: "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows." Its key test: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too."

Two habits make the biggest difference.

Explain the reason behind a rule. Anthropic's example replaces a bare "NEVER use ellipses" with an explanation that the text will be read aloud by a text-to-speech engine that cannot pronounce them. The model can then generalize to similar cases you did not list.

Say what to do, not only what to avoid. Anthropic suggests replacing "Do not use markdown in your response" with "Your response should be composed of smoothly flowing prose paragraphs."

A vague prompt and a specific one:

Write release notes.

Write release notes for version {{version:2.4.0}} of our CLI from the commit list below.
Audience: existing users who upgrade by running one command.
Group changes under Added, Changed and Fixed. One line per change, plain language,
no commit hashes. If a change breaks existing behavior, start its line with "Breaking:".

How should you structure a long prompt?

Separate the parts so the model cannot confuse instructions with data. All three vendors suggest delimiters:

• Anthropic says XML tags "help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs."
• OpenAI suggests a developer message with sections for identity, instructions, examples and context, "usually in this order (though the exact optimal content and order may vary by which model you are using)."
• Google's prompt design strategies for Gemini 3 recommend XML-style tags or Markdown headings and add: "Choose one format and use it consistently within a single prompt."

A skeleton that works with all three:

<role>
You review pull requests for a TypeScript monorepo.
</role>

<instructions>
1. Read the diff and the linked issue.
2. List bugs first, then risky changes, then style notes.
3. Quote the line for every finding.
</instructions>

<context>
{{diff}}
</context>

Role and standing rules usually belong in the system prompt. See what is a system prompt for where that lives in each API.

Where should long documents go in a prompt?

Put long material first and the question last. Anthropic advises placing long documents "near the top of your prompt, above your query, instructions, and examples," and reports that "Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs." Google's Gemini 3 guidance matches: "supply all the context first. Place your specific instructions or questions at the very end of the prompt."

Two refinements from the same docs:

• Ask for quotes first. For long documents, Anthropic suggests asking the model to quote the relevant parts before doing the task, which helps it ignore the rest.
• Bridge the gap. Google suggests a transition phrase after a large block of data, such as "Based on the information above..."

OpenAI adds a cost angle: keep content you reuse on every request at the beginning of the prompt so prompt caching can reuse it. For how much fits and what it costs, see LLM tokens explained and context engineering.

How do examples improve a prompt?

Examples show the model what good output looks like, which is often clearer than describing it. Anthropic calls examples "one of the most reliable ways to steer Claude's output format, tone, and structure," and Google's guide goes further: "We recommend to always include few-shot examples in your prompts."

The main risk is that the model copies surface details, so vary your examples and keep their format identical. The full technique, including how many to use and how reasoning models respond to them, is in few-shot prompting.

Should you still tell the model to think step by step?

Less than you used to. Most current models reason internally before they answer, and the vendors now steer that reasoning with a setting rather than prompt text:

• OpenAI's reasoning best practices say prompting reasoning models to "think step by step" or "explain your reasoning" is unnecessary.
• Google says that for Gemini 2.5 and 3 models "it's generally not necessary to have the model outline, plan, or detail reasoning steps in the returned response itself."
• Anthropic says a prompt such as 'think thoroughly' "often produces better reasoning than a hand-written step-by-step plan," and warns that on several of its newest models a prompt asking the model to write its reasoning into tags "may be declined."

OpenAI also frames the difference between model types: "A reasoning model is like a senior co-worker. You can give them a goal to achieve and trust them to work out the details." GPT models without heavy reasoning benefit from more explicit instructions. The full story, including when manual reasoning prompts still help, is in chain of thought prompting.

How do you get output in a fixed format?

For simple formats, describe the format and show an example. For anything your code has to parse, use the API's structured output feature, which constrains the response to a JSON Schema. Google's prompting guide says that while you can describe simple JSON in a prompt, it recommends its structured output feature "when specifying a more complex JSON Schema for the response."

On Claude, an older trick is gone: Anthropic says prefilled responses on the last assistant turn are no longer supported starting with Claude 4.6 models, and points to structured outputs instead. See LLM structured output for how each vendor implements it.

When should you split a task into several prompts?

When you need to inspect or control the steps in between. Google lists three patterns: break instructions into one prompt per instruction, chain prompts so "the output of one prompt in the sequence becomes the input of the next prompt," and aggregate results from parallel prompts.

Anthropic notes that "With adaptive thinking and subagent orchestration, Claude handles most multistep reasoning internally," but that explicit chaining "is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure." Its most common pattern is self-correction: generate a draft, have the model review it against criteria, then have it refine based on the review, each as a separate call you can log.

How do you iterate on a prompt?

Change one thing at a time and re-run your test inputs. Google's guide opens with the reminder that "Prompt engineering is iterative," and suggests three moves when a prompt stalls:

1. Rephrase. Different wording often gives different results.
2. Switch to an analogous task. Its example turns an open categorization request into a multiple-choice question to stop the model from answering in full sentences.
3. Reorder the content. Try examples, context and input in a different order.

OpenAI now recommends keeping production prompts in your application code rather than in saved prompt objects, so they go through code review, tests and normal deployment. It is deprecating reusable prompt objects, and its guide says v1/prompts "is scheduled to shut down on November 30, 2026."

For coding agents, the same ideas apply to instruction files and skills. See Claude Code best practices and how to write a SKILL.md.

Where should you keep prompts that work?

Somewhere versioned and easy to search, so a prompt you tuned last month is not lost in a chat history. Kipt keeps prompts as Markdown files in a private GitHub repo you own, with {{name}} or {{name:default}} blanks for the parts that change, tags, and Cmd+K search. The free SKILL.md generator can also turn a prompt you reuse often into an Agent Skill.

What should you read next?

Start with the technique you use most. Few-shot prompting covers examples in depth, chain of thought prompting explains reasoning on current models, and LLM structured output covers JSON Schema output. If you want ready-made starting points, browse prompt templates.