A field guide to prompting techniques

A good prompt isn't a magic incantation — it's a specification. You're telling a language model what to produce, what to consider, and what to ignore. The techniques below are the ones that reliably move accuracy on real tasks. They're not alternatives to each other; they're layers you combine.

The baseline: zero-shot

Zero-shot is "just ask." No examples, no scaffolding. You rely entirely on what the model learned during training.

Summarize the following support ticket in one sentence, naming the product and the user's problem. Ticket: …

It's the right starting point for anything you can describe unambiguously in one or two sentences. If zero-shot works, stop. Fancier techniques cost tokens, latency, and risk — don't pay for them unless the baseline fails.

Few-shot: show, don't tell

When a task has a specific shape — a format, a style, a rubric that would take a paragraph to describe — show examples instead.

Rewrite each sentence in the plain-English style of the examples.

Input:  Our platform leverages synergistic cross-functional alignment.
Output: We help teams work together.

Input:  We provide best-in-class omnichannel engagement.
Output: We make it easy for your customers to reach you.

Input:  <your sentence here>
Output:

Three examples is usually enough. Beyond five or six, you're often overfitting the model to incidental features of your examples.

Role prompting: set the context, not a costume

"You are a world-class senior engineer who thinks step by step" is cargo-culted everywhere. The useful version of role prompting is specific:

• What the responder knows ("You review code for a payments team that cares about idempotency and PCI boundaries.")
• Who the audience is ("Explain this to a reader who knows calculus but has never seen linear algebra.")
• What voice to use ("Reply in two short paragraphs, no lists.")

Flattery doesn't make a model smarter. Context does.

Chain-of-thought: let it think out loud

Many models answer better when you ask them to reason step by step before giving a final answer. This is chain-of-thought (CoT).

A train leaves Berlin at 09:00 traveling 120 km/h. … Think through this step by step, then give the final answer on a line starting with "Answer:".

CoT is especially useful for multi-step arithmetic, logic puzzles, causal reasoning, and any task where skipping the middle leads to confident wrong answers. The newer "reasoning" models (o-series, R1- style) do this internally — explicit CoT in your prompt helps less there, and can sometimes hurt.

Self-consistency: vote across chains

If CoT works but is still occasionally wrong, run it several times at nonzero temperature and take the majority answer. This is self-consistency. It costs N× the tokens and gains the most on tasks with discrete answers (math, multiple choice). It gains less on open-ended writing, where "majority" doesn't mean much.

ReAct and tool use: reason, then do

If the task requires facts the model doesn't have — current prices, your database, a web search — you need the model to use tools. ReAct ("reason + act") is the pattern:

Thought: I need the current share price of SIE.DE.
Action: web_search("SIE.DE stock price")
Observation: 212.40 EUR, 2026-10-27
Thought: Convert to USD at today's rate.
Action: fx("EUR", "USD", 212.40)
Observation: 227.32 USD
Final answer: SIE.DE is at ~$227 as of today.

Agentic systems are ReAct turned up to eleven: a planner, a toolset, and sometimes several cooperating agents. The orchestration framework matters less than the clarity of each tool's contract.

Structured output: parseability as a feature

The moment a prompt's output is consumed by code, ask for a structured format. Most frontier models support JSON schemas directly:

Extract fields matching this schema. If a field is unknown, use null.
Return only JSON.

Schema:
  customer:  string
  issue:     string
  severity:  "low" | "med" | "high"

If your API doesn't support schema-constrained decoding, add two guardrails to your prompt: an exact example of the output shape, and "Do not include any text before or after the JSON." Then validate on the parsing side and retry on failure.

Prompt chaining: break hard tasks into easy ones

A single prompt that tries to classify, extract, summarize, and rank usually does none of them well. Chain small prompts, each with one clear job:

1. Classify the request type.
2. Extract the entities relevant to that type.
3. Lookup anything external.
4. Compose the final answer.

Each step is simpler, easier to evaluate, and easier to swap for a smaller cheaper model. Most production LLM features look like this under the hood, even when they're pitched as "one call."

When fancier isn't better

• Short factual lookups rarely benefit from CoT.
• Creative writing rarely benefits from few-shot — the examples anchor the output to their vibe.
• Reasoning-model prompts often get worse with explicit "think step by step" boilerplate.
• Very long instructions at the top of a prompt get ignored once the model is deep into a response. Put the most important constraints last, closer to where the model will "look" when generating.

A rough decision tree

• Can you describe the task in two sentences? → Zero-shot.
• Does it have a specific shape or style? → Few-shot (3 examples).
• Does it need multi-step reasoning? → Chain-of-thought.
• Is correctness non-negotiable and the answer discrete? → Add self-consistency.
• Does it need external facts or state? → ReAct with tools.
• Is the output consumed by code? → Structured output with a schema.
• Is it still unreliable? → Chain smaller prompts, each with one job.

Prompting is a cheap-to-change layer. Keep your prompts in version control, evaluate them against a small golden set, and treat every "let me just add one more line to the system prompt" as a code change that deserves a review.