Prompting Techniques — An Overview

Redaktion · 2. Mai 2026

Why the choice of prompting technique matters

Language models are sensitive to how you phrase an instruction. The same task, in two different wordings, produces noticeably different output — sometimes by large factors. That is not a bug; it follows from how an LLM works. It predicts the next token based on context. Whatever sits before the cursor decides what comes next.

Over the years, nine patterns have emerged that keep showing up in research and practice: zero-shot, few-shot, chain-of-thought, self-consistency, self-refine, tree of thoughts, ReAct, role/meta-prompting, and context engineering. None is universally best. Each has a class of problems where it shines and several where it just burns tokens without improving the answer. This article sorts the techniques, explains the mechanics, and ends with a rule-of-thumb table to help you pick faster.

System prompt, user prompt, template — what a prompt is built from

Before the techniques, a quick stage-setting note. A modern LLM call typically consists of two parts: a system prompt that sets behavior once per session (“You are a precise SQL reviewer, answer in three sentences max”), and a user prompt with the actual task. The techniques below operate on both — mostly in the user prompt, some (role-prompting) more naturally in the system prompt.

Distinct from those are prompt templates: structures with placeholders, filled in code at runtime. Templates are not a technique themselves — they are the delivery mechanism, capable of carrying any of the nine patterns.

Core mechanics: what a prompt pattern actually does

Each technique turns one of three knobs: examples in context (few-shot shows the model what the output should look like), reasoning steps in the output (chain-of-thought makes the model think first, answer second), or multi-call orchestration (self-consistency and ReAct generate more than one response and choose between them). If you remember which knob a given technique turns, you also know when it becomes redundant.

The nine techniques

Zero-shot

Just ask. No examples, no reasoning instruction. “Translate this text into English.” As simple as it sounds.

Mini example: “Classify this email as ‘complaint’, ‘inquiry’, or ‘praise’. Email: …”

When it pays off: clearly framed tasks with an unambiguous answer — translation, classification, simple extraction. Modern models (Claude 4.7, GPT-5) are now strong enough at zero-shot that many tasks which needed few-shot two years ago are done in one line. Default starting point — only escalate when the result falls short.

Few-shot

Drop three to five examples of the desired input/output pair into the prompt, then state the actual task. The model picks up the format and the logic from the examples.

Mini example:

Email: "When does my package arrive?" → Inquiry
Email: "Great service, thanks!" → Praise
Email: "Third time this delivery is late!" → Complaint
Email: "..." →

When it pays off: tasks whose format is hard to describe but easy to show — structured extraction into uncommon JSON schemas, style imitation, domain-specific classification. Watch out: examples shape the output strongly. If all three are three lines long, the model will answer in three lines too — whether the real task warrants it or not.

Chain-of-thought (CoT)

Tell the model to spell out the intermediate steps before the answer. Classic phrasing: “Let’s think step by step.” For multi-step tasks — math, logic, multi-part research — this lifts accuracy measurably.

Mini example: “A library has 1,340 books. 12 % are removed, then 200 new ones are added. How many books? Think step by step.”

When it pays off: anywhere the answer follows from multiple intermediate calculations. With reasoning models (Claude with extended thinking, GPT-5 with reasoning) CoT is partly built in already — explicit “think step by step” becomes redundant and just costs tokens. Check whether the model already reasons internally before bolting it on.

Self-consistency

A variant of CoT. Instead of one chain-of-thought, generate five to ten — with higher temperature, i.e. more randomness. Then pick the answer that shows up most often. Majority vote instead of single shot.

Mini example: solve the same math problem eight times at temperature 0.7, then take the most frequent result.

When it pays off: tasks with a clearly discrete answer and a high single-shot error rate — math, logic puzzles, multiple-choice classification. Costs 5–10× the tokens of a single run, so only worth it when the task is.

Self-refine

The model writes a first answer, critiques it itself, then writes a revised version. Two or three rounds, then stop. Works well for tasks with a clear quality criterion the model can judge — code style, argument clarity, translation smoothness.

Mini example: “Write a product description. — Read it and list three weaknesses. — Rewrite the description based on the critique.”

When it pays off: creative or argumentative output where “better” is easy to recognize. Self-refine breaks down when the model fails to spot the flaws — then more rounds produce change but no improvement.

Tree of thoughts (ToT)

Instead of a linear chain, build a tree of thoughts: explore multiple paths in parallel, evaluate each, prune the weak ones, deepen the promising ones. Rarely implemented as pure ToT in production — more common as inspiration for orchestrated multi-step solutions with candidate selection.

Mini example: for a planning task, sketch three alternative approaches, score each with two sentences, pursue the best one.

When it pays off: exploratory tasks with real branching — game moves, strategy drafts, creative concept work. Token-heavy and tricky to orchestrate — usually a job for a dedicated agent framework, not a single-shot prompt.

ReAct (reason + act)

The model alternates between thinking (Thought) and acting (Action) — action meaning: call a tool, run a search, hit an API. After each action the environment returns an observation, the model reasons further, calls the next tool. ReAct is the standard loop for agentic systems.

Mini example:

Thought: I need the current weather in Hamburg.
Action: weather_api(city="Hamburg")
Observation: 12°C, rainy
Thought: With that I can give the recommendation.

When it pays off: as soon as the answer needs external information or tool calls. Function calling and MCP are the infrastructure, ReAct is the behavior pattern on top. Pitfall: without a hard stop condition, the model can call tools forever — always set a token budget and step cap.

Role-prompting & meta-prompting

Two closely related techniques. Role-prompting assigns the model a role (“You are an experienced SQL reviewer with 15 years of database work”). That shifts vocabulary and depth toward that role. The effect is measurable but moderate — role alone, without further instruction, rarely makes the difference between a bad and a good answer.

Meta-prompting goes one level up: have the model design a good prompt for the actual task, then use that. Useful when bootstrapping reusable prompts or onboarding a new model whose triggers you don’t yet know.

When it pays off: role-prompting as a complement to other techniques, especially in the system prompt. Meta-prompting during the development phase of a workflow, less so in production.

Context engineering

The youngest member of the family and the one with the biggest leverage. Context engineering is the craft of placing exactly the information the model needs into context — and nothing beyond. The individual techniques (zero-shot, few-shot, CoT) are tools; context engineering is the question of what is in the toolbox to begin with.

Concretely: feeding in relevant documentation via retrieval, summarizing past turns deliberately, trimming irrelevant tool returns from the history, ordering prompt blocks consciously (important instructions at the end — recency bias). In long sessions or agentic workflows, context engineering often decides quality more than any prompt technique in the narrow sense.

Rule of thumb: which technique for which task

| Task type | First choice | If that’s not enough | |---|---|---| | Translation, classification, simple extraction | Zero-shot | Few-shot with 3–5 examples | | Structured extraction (JSON, uncommon schemas) | Few-shot | Few-shot + schema in system prompt | | Multi-step calculation or logic | Chain-of-thought | Self-consistency (5–8 runs) | | Creative writing with a quality criterion | Zero-shot | Self-refine over 2 rounds | | Research, tool calls, real-time data | ReAct | + step cap and token budget | | Exploratory planning, strategy drafts | Tree of thoughts (orchestrated) | Multi-agent framework | | Reusable workflow prompt | Meta-prompting during development | + templating in code | | Long sessions, agentic loops | Context engineering (always) | + history summarization |

The right column is the escalation rung. Always start on the left — zero-shot is surprisingly often enough. Starting with self-consistency or tree of thoughts wastes tokens and time.

Pitfalls

Reasoning is often baked in already. With current reasoning models running extended thinking, an internal CoT runs before the output starts. An additional “think step by step” becomes redundant, costs tokens, and can even hurt the answer because the model produces two nested reasoning chains. Check whether the model reasons internally before bolting it on.

Few-shot over-imprints the format. If all three examples produce JSON, the model will produce JSON in edge cases too, even when the content does not warrant it. Examples need to span the variance of the real task, not just the happy path.

Tree of thoughts and self-consistency are expensive. Both multiply token cost linearly with the number of parallel paths. For a task already 95 % correct in single-shot, the 5× surcharge rarely earns its keep.

ReAct without a stop condition leads to infinite loops. When the model learns “call another tool” as its default, a workflow can spiral. Always work with a hard step ceiling and token budget.

Role-prompting alone does little. “You are an expert in X” without further instruction is barely measurable. Role is seasoning, not the main course.

What does not belong in this article

Prompting has a security dimension — prompt injection, jailbreaks, prompt leaking, guardrails. That is its own discipline with its own techniques (spotlighting, input sanitization, tool whitelisting) and belongs in the sister article on prompt security.

Tool use in the narrower sense (function calling, MCP, structured output) shows up here only as a behavior loop — the mechanics of tool calls themselves belong in the agents domain.

Conclusion

Prompting techniques are not secret knowledge. They are a small collection of patterns that have proven themselves in practice. Knowing them gives you a toolbox; using them all at once just bloats your prompt without making it better or cheaper.

Practical heuristic: start with zero-shot. If the result is off, ask yourself why. Wrong format → few-shot. Calculation errors → chain-of-thought or self-consistency. External data missing → ReAct. Model loses the thread in long sessions → context engineering. You rarely need more.

One last point: models keep evolving. A technique that was necessary in 2023 can be redundant in 2026 because the model already does the step internally. Audit your prompt stack against the current default behavior every few months — tokens you save are latency you gain.

Entdecke mehr

Blog

Themenuebersicht

KI-Konzepte Prompting