Core Techniques
With the anatomy in place, this chapter covers the principal techniques of prompt engineering. These are not mutually exclusive. Expert practitioners combine them fluidly based on task requirements. Understanding each one individually is the prerequisite for knowing when and how to combine them.
Zero-Shot Prompting
Zero-shot prompting is the most basic technique: you describe the task and expect the model to perform it without examples. This works reliably for tasks the model has encountered frequently during training in similar forms. It is the appropriate starting point for any prompt, and for many tasks it is sufficient.
Zero-shot prompts fail when the task requires a specific output format the model cannot infer from the instruction alone, when the task involves domain-specific conventions the model may not have encountered in training, or when the instruction is ambiguous in ways the model cannot resolve without additional signal.
The performance ceiling of zero-shot prompting scales with the precision of the task instruction. A highly specific zero-shot prompt often outperforms a vague few-shot prompt. Technique selection should not substitute for instruction quality.
Few-Shot Prompting
Few-shot prompting provides the model with one or more examples of the desired input-output mapping before presenting the actual task. The examples serve as in-context demonstrations that shift the model's probability distribution toward outputs matching the demonstrated pattern.
The power of few-shot prompting comes from its ability to communicate output requirements that are difficult to specify precisely in natural language. If your desired output has a particular structure, tone, or analytical approach that would take many words to describe, showing the model a well-chosen example is often more efficient and more reliable than describing it.
Example:
Classify the following customer messages by sentiment and urgency.
Use the format shown.
Message: "I've been waiting three weeks and still no delivery confirmation."
Classification: Sentiment: Negative | Urgency: High
Message: "Just checking in on my order from last Tuesday."
Classification: Sentiment: Neutral | Urgency: Low
Message: "The product arrived damaged and I need a replacement immediately."
Classification:Several properties of good few-shot examples are worth noting. They should be representative of the range of inputs the model will encounter, not just the easiest cases. They should demonstrate the edge cases and nuances that are most important to get right. And they should be consistent: if your examples are internally inconsistent in format or judgement, the model will produce inconsistent output.
The number of examples required varies by task complexity. One or two examples are often sufficient for format demonstration. More complex classification or analytical tasks may benefit from five to ten. Beyond ten examples, the marginal benefit typically diminishes, and the cost in context window tokens increases.
Chain-of-Thought Prompting
Chain-of-thought (CoT) prompting instructs the model to reason through a problem step by step before producing a final answer. It was introduced as a formal technique in research by Wei et al. (2022) and has since become one of the most consistently effective approaches for tasks involving multi-step reasoning, arithmetic, logical inference, and complex decision-making.
The underlying mechanism is straightforward. By generating intermediate reasoning steps, the model conditions each subsequent step on an increasingly precise representation of the problem, rather than attempting to leap directly from input to output. This reduces the likelihood of errors that arise from compressed reasoning.
The simplest implementation is to append a phrase such as "Think through this step by step before giving your final answer" to the task instruction. This alone produces measurable improvements on reasoning tasks. A more controlled implementation provides a structured reasoning template:
For the highest-stakes reasoning tasks, few-shot chain-of-thought combines both techniques: you provide examples that include the full reasoning chain, not just the final answer. This gives the model a demonstrated template for the reasoning process itself, not just the output format.
One important caveat: chain-of-thought prompting increases response length significantly, as the model generates its reasoning before its conclusion. For tasks where response brevity matters, or where the reasoning process is not itself valuable output, simpler techniques may be more appropriate.
Role Prompting
Role prompting assigns the model an expert identity before presenting a task. It is closely related to the role definition layer in system prompt construction, but can also be applied at the individual prompt level when no system prompt is configured, or when a task requires a different expertise frame than the one established in the system prompt.
Role prompting works by activating the model's learned associations between an expert identity and the knowledge, reasoning patterns, vocabulary, and communication style that characterise that identity. Telling the model it is a senior security auditor before asking it to review an architecture document will produce a response that is more likely to apply security-relevant analytical frameworks than a response generated without that framing.
Effective role prompts are specific. "You are an expert" is not a role. "You are a principal engineer with fifteen years of experience designing distributed systems at scale" activates a much more specific cluster of knowledge and reasoning patterns.
Role prompts should be used deliberately and reset between tasks when the required expertise changes significantly. A role established for one task can subtly bias subsequent responses if not cleared.
Instruction Decomposition
Instruction decomposition is the practice of breaking a complex task into a sequence of simpler subtasks, each handled by a separate prompt. It is the prompt engineering equivalent of functional decomposition in software development: dividing a problem into components that are individually tractable.
Complex tasks fail for several reasons when approached as a single prompt. The instruction may be too long for the model to maintain full attention across all components simultaneously. The task may involve subtasks that require different reasoning modes, such as analysis followed by creative synthesis. Or the output of one subtask may need to be reviewed or modified before being passed to the next.
Decomposition addresses all of these failure modes. It also makes debugging easier: when a multi-step process fails, a decomposed prompt sequence allows you to isolate which step introduced the error.
A practical example: producing a research briefing might be decomposed into (1) extracting key claims from a source document, (2) evaluating the credibility and relevance of each claim, (3) identifying gaps or contradictions, and (4) synthesising a structured briefing. Each step uses the output of the previous one as input, and each can be evaluated and corrected independently.
Retrieval-Augmented Prompting
Retrieval-augmented prompting extends the standard prompt by injecting relevant external content into the context window before the task instruction is processed. In GLBNXT Workspace, this is implemented through the knowledge base and RAG (Retrieval-Augmented Generation) pipeline, which automatically retrieves relevant document chunks and prepends them to the model's context.
When constructing prompts in a RAG-enabled environment, it is important to write instructions that explicitly reference the retrieved context rather than assuming the model will integrate it automatically. Instructions such as "Based on the documents provided, answer the following question" or "Using only the information in the context below, summarise the key findings" direct the model to ground its response in the retrieved material rather than drawing on parametric knowledge that may be outdated or less precise.
Equally important is the instruction to flag when retrieved context is insufficient. "If the provided documents do not contain enough information to answer the question, state this explicitly rather than speculating" prevents the model from confabulating plausible-sounding content when the retrieved context is incomplete.
Last updated
Was this helpful?