Prompt engineering: a practical guide with examples

A prompt is the main lever you have over a language model's behavior at run time, so small wording changes can swing quality, cost and reliability. This guide breaks a prompt into its parts, covers the principles that matter most, walks through eight techniques with before-and-after examples, explains what changes with reasoning models as of October 2026, and ends with a template you can reuse.

The advice applies to chat apps and APIs alike. If the term is new to you, the prompt engineering glossary entry is a one-minute primer.

What a prompt is made of

Most effective prompts combine five parts. You won't need all five every time, but knowing them makes it obvious what a weak prompt is missing.

In an API call, the stable parts (role, rules, format, examples) usually go in the system prompt or developer message, while the changing input goes in the user message. That split keeps behavior consistent across requests and lets prompt caching reuse the repeated prefix, which lowers cost and latency.

Every part also costs tokens. A 1,500-token system prompt sent with 200,000 requests a month adds up to 300 million input tokens before any user text, so cut anything that doesn't change the output. The token counter shows what yours costs.

Core principles

Be specific

Vague requests get generic answers because the model fills the gaps with the most average interpretation. Name the audience, length, scope and what a good result looks like.

Before:
Write about our new feature.

After:
Write a 120-word announcement of our new CSV export for existing
customers of a payroll app. Lead with the benefit (exports open
cleanly in Excel), say it's included on every plan, and end with
one sentence on where to find it (Settings > Reports).

Give context and purpose

Explaining why a rule exists helps the model apply it to cases you didn't foresee. "Keep answers under 40 words" is a rule. "Keep answers under 40 words because they appear in a phone notification" is a rule the model can generalize, for example by also dropping greetings and sign-offs.

Show examples

One or two worked examples often communicate format and tone faster than a paragraph of description. Anthropic's current guidance suggests three to five varied examples, while OpenAI advises starting reasoning models with none and adding examples only if needed. Either way, examples must agree with your written instructions, because models tend to copy the examples when the two conflict.

Specify the format

State exactly what the output should look like: prose or bullets, length, headings, fields, units, date formats. If code will parse the response, enforce a schema, covered below, rather than hoping the model stays consistent.

Set constraints

Constraints mark the boundaries: which sources to use, a word limit, a reading level, what to do when information is missing. Phrase them positively where you can, since "write in plain paragraphs" works better than "don't use Markdown." Save absolute words like "always" and "never" for true invariants such as security rules or required fields.

Techniques with before-and-after examples

Role and system prompts

A one-line role in the system prompt sets vocabulary, depth and tone. It works best when it names the audience and the job, not just an impressive title.

Before (user message only):
Explain this error log.

After (system prompt):
You are a senior site-reliability engineer helping a junior developer.
Explain errors in plain language, name the most likely root cause
first, and give one command they can run to confirm it.

Don't rely on a role for security. System prompts can be extracted or overridden, so permissions belong in code, as the LLM security guide explains.

Few-shot examples

Few-shot prompting means including input-output pairs so the model can copy the pattern. It's especially effective for classification, extraction and matching a house style.

Before:
Tag the sentiment of this review: "Shipping took forever but the
blender is great."

After:
Tag sentiment as positive, negative or mixed.

Review: "Arrived early, works perfectly."
Sentiment: positive

Review: "Broke after two uses. The refund took a month."
Sentiment: negative

Review: "Shipping took forever but the blender is great."
Sentiment:

Vary your examples so the model doesn't learn an accidental rule, and include at least one tricky case.

Step-by-step decomposition

When a task has distinct stages, list them. The model is less likely to skip one, and you can see exactly which stage goes wrong.

Before:
Is this vendor proposal any good?

After:
Evaluate the vendor proposal below in three steps:
1. Summarize what they will deliver, by when, and for how much.
2. List anything missing that a fixed-price IT project normally includes.
3. Rate the proposal as strong, acceptable or weak, with two reasons.

This structures the output so you can review it. It isn't the same as telling a model how to think internally, which the next technique covers.

Asking for reasoning vs using a reasoning model

With a standard model, asking it to reason before answering, known as chain-of-thought prompting, often improves multi-step math and logic. The 2022 research that named the technique showed large gains simply from including worked reasoning in the examples.

A reasoning model already reasons internally before it writes the answer. Adding "think step by step" is redundant at best, and OpenAI's guidance notes it can hurt. Control depth with the API's effort or thinking setting instead, and spend the prompt on the goal and the success criteria.

Standard model:
Solve the problem below. Work through it step by step, then give
the final answer on its own line, starting with "Answer:".

Reasoning model (effort is set in the API call, not the prompt):
Solve the problem below. Give the final answer on its own line,
starting with "Answer:".

Self-critique and revision

Models catch more of their own errors when reviewing is a separate step with explicit criteria. The most dependable version uses two calls: one drafts, the other checks the draft against a list and rewrites it.

Before:
Write a product description for our hiking boots.

After (second call, with the draft attached):
Review the draft below against these criteria:
- Mentions weight, waterproofing and sizing advice
- Under 150 words
- No claims we can't prove, such as "best" or "lightest"
List each criterion it fails, then output a corrected version.

Check this against your model, though. Anthropic advises removing carried-over self-check instructions for Claude Opus 5, which verifies its own work by default and can over-verify when told to.

Structured JSON output

When software consumes the answer, ask for JSON and enforce it with your provider's structured outputs feature, which constrains the model to a JSON Schema you supply. OpenAI and Google both recommend schema enforcement over describing the format in prose.

Before:
Pull the key details out of this invoice.

After (instruction plus a schema passed to the API):
Extract the invoice fields. Use null when a field is missing; never guess.

{
  "type": "object",
  "properties": {
    "vendor": {"type": "string"},
    "invoice_date": {"type": ["string", "null"], "description": "YYYY-MM-DD"},
    "total": {"type": ["number", "null"]},
    "currency": {"type": ["string", "null"], "description": "ISO 4217 code"}
  },
  "required": ["vendor", "invoice_date", "total", "currency"],
  "additionalProperties": false
}

Keep a validation step anyway, because a valid shape can still hold a wrong value. The old trick of pre-filling the assistant's reply with an opening brace no longer works on newer Claude models, which reject a prefilled final assistant turn, so schema features are the durable approach.

Delimiters

Delimiters such as XML-style tags, Markdown headings or triple quotes separate your instructions from the material they act on. They stop the model from confusing a pasted document with your request and make long prompts easier to maintain.

Before:
Summarize this for the board: [three pages of meeting notes]

After:
<meeting_notes>
...pasted notes...
</meeting_notes>

<instructions>
Summarize the meeting notes above for the board in five bullets.
Flag any decision that changes the budget.
</instructions>

For long inputs, put the documents first and the question last. Anthropic reports quality gains of up to 30 percent in its tests from that ordering on complex, multi-document prompts. Delimiters aren't a security boundary, though: text inside the tags can still carry a prompt injection.

Prompt chaining

Prompt chaining splits a job into a sequence of focused calls, where each output feeds the next. You get inspectable intermediate results, the option to use a cheaper model for simple steps, and room for code checks in between.

Step 1 (small, fast model): Extract every customer complaint from
these 40 reviews as a JSON list.
Step 2 (plain code): Remove duplicates and count complaints by theme.
Step 3 (stronger model): Write a one-page summary of the top five
themes for the product team, with two quotes each.

Chaining adds latency and failure points, so use it when one prompt keeps failing or you need to audit the middle steps. Let the model choose the steps and call tools, and it becomes an AI agent.

Prompting reasoning models in 2026

Reasoning models think before they respond, and that has overturned some long-standing advice. Here is what the three largest API providers recommend as of October 2026, based on their current documentation.

The common thread is a shift from scripting the process to specifying the outcome. Older prompts spelled out every step because earlier models needed it. With reasoning models, that detail can block a better approach the model would have found on its own, which is why OpenAI's GPT-5.5 guidance favors outcome-first prompts with success criteria and stop conditions over step-by-step process instructions.

• Specify success, not steps. State the goal, the constraints, what a correct answer must contain and when to stop.
• Tune effort before wording. Hidden reasoning tokens are billed, so test lower effort first. Many classification and extraction tasks don't need high effort.
• Leave sampling settings alone. Some reasoning models don't accept temperature changes at all, and Google warns that lowering temperature on Gemini 3 can cause looping.
• Retest when you upgrade. An instruction that helped one generation, like "double-check everything," can cause overthinking or over-verification in the next.

Testing and versioning prompts

A prompt is code running on a probabilistic interpreter, so treat changes like code changes. This workflow is light enough for a solo developer and scales to a team.

1. Build a test set. Collect 30 to 100 real inputs, including edge cases and past failures, each with an expected output or a pass/fail rubric.
2. Score automatically where possible. Use exact-match or schema checks for structured output, and an LLM-as-a-judge with a clear rubric for open-ended text, spot-checked by a person.
3. Change one thing at a time. Rerun the full set after each edit and compare pass rate, cost and latency with the previous version.
4. Version everything. Keep prompts in your repository with IDs, review changes like code, and log the prompt version and model snapshot with every production output.
5. Pin model versions. Use dated model snapshots in production so a silent update can't change behavior, and rerun your tests before switching.

OpenAI's documentation now recommends keeping production prompts in application code under tests and code review. Its hosted prompt objects are being retired, with that endpoint scheduled to shut down on November 30, 2026.

Run each test case more than once. Outputs vary, so a prompt that passes 46 of 50 cases on one run may pass 43 on the next; treat gaps of a few cases as noise until a second run confirms them. Watch cost too: five 200-token examples add 1,000 input tokens per call, which at 500,000 calls a month and $2 per million input tokens is $1,000 a month. The benchmarks guide covers how to size and score an evaluation set.

Common mistakes

• Burying the task. Three paragraphs of background before the actual request makes the model guess what matters. Lead with the task.
• Contradicting yourself. "Be concise" in the system prompt and "explain thoroughly" in the user message forces the model to pick one, unpredictably.
• Examples that break the rules. If your instructions say 50 words and your examples run to 120, expect 120.
• Shouting. All-caps warnings and stacked "CRITICAL" labels make newer models overreact.
• Asking for facts the model can't know. Recent events and your internal data must be supplied, typically through retrieval; otherwise you invite hallucinations.
• Testing on one input. A prompt that works on your favorite example can fail on a third of real traffic.
• Porting prompts unchanged. Wording tuned for one model or generation often underperforms on another.

A reusable prompt template

Copy this skeleton, delete the sections you don't need and fill in the rest. Stable material comes first, which also helps prompt caching, and the changing input comes last.

# Role
You are a [role] helping [audience] with [job].

# Goal
[One or two sentences: the outcome you want and why it matters.]

# Context
[Facts the model can't know: product details, policies, definitions.]

# Instructions and constraints
- [Rule, with the reason if it isn't obvious]
- [Scope, sources to use, length, reading level]
- If information is missing, [ask / reply "unknown" / use null].

# Examples
<example>
Input: [...]
Output: [...]
</example>

# Success criteria
A good answer [contains X], [stays under N words], [cites the source].
Stop when [condition].

# Output format
[Prose / bullets / JSON matching the supplied schema]

# Input
<input>
{{user_input}}
</input>

Before you ship a prompt built from the template, run through this list:

Next steps

Turn the template into a working prompt with the prompt builder, which walks you through role, task, context, format and constraints. Browse the prompt library for tested starting points by use case.

If prompting alone isn't getting you there, fine-tuning vs RAG vs prompting will help you decide what to try next. Teams that want a hands-on review of production prompts and evaluations can get help from LLM specialists.