Skip to main content

​
Overview

The fundamentals tell you what a good prompt contains. The techniques below tell you how to compose those contents for specific kinds of tasks. Each technique has a specific use case, a specific failure mode, and a specific cost in tokens. Knowing when to reach for which is most of the craft.

Zero Shot Prompting

Ask directly without examples. Best for simple, well known tasks.

Few Shot Prompting

Include two to five examples in the prompt. Best for formatting and classification.

Chain of Thought

Ask the model to reason step by step. Best for math, logic, and multi step decisions.

Role Prompting

Assign a persona or expertise. Best for tone control and domain specific tasks.

Prefilling

Start the assistant turn for the model. Best for enforcing format and bypassing preamble.

Prompt Chaining

Split a hard task across multiple prompts. Best for long workflows and complex pipelines.

​
Zero Shot Prompting

Zero shot is the default mode: you describe the task and the model performs it without examples. Modern instruction tuned models are remarkably strong at zero shot for tasks that are common in their training data: summarization, translation, sentiment classification, basic extraction, basic reasoning.
When zero shot works, use it. It is cheaper, easier to maintain, and scales better than prompts loaded with examples. Reach for few shot only when zero shot is producing inconsistent or wrongly formatted output. A useful mental check: if you can describe the task in one sentence and the format in one sentence, try zero shot first. Add examples only when you have evidence that they help.

​
Few Shot Prompting

Few shot prompting includes two to five examples of input and output in the prompt itself. The model infers the pattern from the examples and applies it to the new input. Few shot is especially powerful for:
  • Classification with custom labels. When your taxonomy is not standard, examples are faster than describing the labels in prose.
  • Format enforcement. When the output must follow a precise structure, an example is worth several paragraphs of instructions.
  • Style transfer. When you want a specific voice, two well chosen examples capture it better than adjectives.
For most tasks, three to five examples is the right number. Two is sometimes enough; more than five rarely helps and starts to bias the model toward surface patterns. The examples should be diverse, not redundant. Three examples covering the same easy case teach the model nothing about the hard cases. Pick examples that span the boundaries of the task: an obvious case, a tricky edge case, and one that includes the kind of input that has previously caused failures. A subtle but important point: for reasoning heavy tasks on the latest models, few shot examples can hurt performance by anchoring the model to surface patterns instead of letting it reason fresh. Use few shot for classification and formatting; prefer zero shot with chain of thought for math and logic.

​
Chain of Thought

Chain of thought, often abbreviated CoT, is the technique of asking the model to produce its reasoning before its answer. The effect is large, well documented, and persists across model generations. Even the simple instruction “Let’s think step by step” produces a measurable improvement on reasoning tasks. The simplest form is zero shot CoT:
For harder problems, structured CoT works better. Wrap the reasoning in XML tags so the reasoning and the answer can be separated programmatically:
A few rules of thumb that hold across providers:
  • Use CoT when the task has multiple steps. Math, multi hop reasoning, planning, debugging.
  • Do not use CoT for retrieval or simple classification. It adds tokens and rarely helps.
  • Modern reasoning models do CoT internally. The latest reasoning oriented models reason before responding by default. Adding “think step by step” to a reasoning model is redundant and sometimes counterproductive.
  • Separate reasoning from answer. Always specify how the final answer is delivered, so you can parse it without parsing the reasoning.

​
Role Prompting

Setting a role at the start of the prompt, usually in the system message, focuses the model’s voice, vocabulary, and depth of knowledge for the entire conversation. Role prompting is one of the highest leverage techniques for steering model behavior, which is why every PANTA OS assistant starts with a clearly defined role in its system prompt.
A few principles for effective role prompting:
  • Be specific about expertise. “You are an expert” is generic. “You are a clinical pharmacist with twenty years of experience in oncology” is steerable.
  • Include the audience. The role should specify who the output is for, not just who is producing it.
  • State the boundary. “Your job is X, not Y” prevents the most common drift, where the model takes on adjacent responsibilities you did not want.
  • Keep it short. A two to four sentence role is enough. Longer roles tend to introduce contradictions.
Role prompting and few shot examples compose well: the role sets the voice, the examples set the format. Use both when you need consistent output in a specific persona.

​
Prefilling

Prefilling is the technique of starting the assistant’s response yourself, so the model continues from where you stopped. It is a powerful but underused method for enforcing format and skipping unwanted preamble. When the API supports it, send an assistant message with the desired beginning. The model continues from there.
Then send an assistant message that begins with { so the model continues with the JSON object instead of writing a preamble like “Here is the extracted information:”. The most common uses of prefilling:
  • Force JSON output. Prefill with { so the model is committed to a JSON response.
  • Force a specific structure. Prefill with <analysis> so the model continues inside the tag.
  • Force a refusal pattern. Prefill with “I cannot help with” to bias toward declining a borderline request.
  • Speak in character. Prefill with the character’s name to keep a roleplay assistant in voice.
Prefilling support varies by provider. Some APIs allow it natively through the messages parameter; others require a workaround.

​
Prompt Chaining

When a task is too complex for a single prompt, split it into a chain of prompts where the output of one becomes the input of the next. Use chaining whenever a single prompt has more than two distinct stages, since each stage gets the model’s full attention rather than competing with the others for it. A typical chain has three stages:
  1. Extraction. Pull the relevant information out of the source.
  2. Transformation. Apply the logic, classification, or analysis to the extracted information.
  3. Composition. Format the result for the destination.
Chaining is the design principle behind PANTA OS Apps: every App breaks a complex output into a sequence of well defined steps, each with its own prompt, often with a Human in the Loop checkpoint between stages. The advantages over a single mega prompt are real. Each stage is easier to debug, easier to evaluate, and easier to swap out. The cost is operational complexity: you now have several prompts to maintain instead of one. A useful heuristic: if a single prompt is more than 1500 tokens of instructions and the model is producing inconsistent output, try chaining before adding more instructions. Smaller, focused prompts almost always outperform sprawling ones.

​
Combining Techniques

The techniques are not mutually exclusive. Most production prompts use three or four of them at once. A canonical structure that combines role prompting, structure, examples, and chain of thought looks like this:
This is roughly the shape of a strong production prompt. Role at the top, task next, examples in tagged blocks, input clearly delimited, and an explicit reasoning and output structure at the end.

​
What Comes Next

The next page, Structured Prompts, goes deeper on the structural side: XML tags, JSON contracts, and the anatomy of a system prompt. The techniques on this page assume you can write a clean structure; the next page shows how.
Last modified on June 1, 2026