# Prompt Engineering Patterns Guide

This guide provides a systematic approach to selecting appropriate prompt patterns for various tasks when working with open-source language models. Implementing the correct pattern significantly improves output reliability and performance.

## Why Patterns Matter
Prompt patterns serve distinct purposes in language model interactions:

- **Zero shot** provides instructions without examples, relying on the model's existing knowledge.
- **Few shot** demonstrates specific examples for the model to follow as templates.
- **Chain of Thought** breaks complex reasoning into sequential steps for methodical problem-solving.

Selecting the appropriate pattern significantly improves output accuracy, consistency, and reliability across applications.

## Pattern Chooser Table

The table below helps you quickly identify the most effective prompt pattern for your specific task, matching common use cases with optimal approaches to maximize model performance.

| Task Type | Recommended Pattern | Why it works |
| --- | --- | --- |
| Simple Q&A, definitions | [**Zero shot**](#zero-shot) | Model already knows; instructions suffice |
| Extraction / classification | [**Few shot (1-3 samples)**](#one-shot--few-shot) | Teaches exact labels & JSON keys |
| Creative writing | [**Zero shot + role**](#zero-shot) | Freedom + persona = coherent style |
| Multi-step math / logic | [**Chain of Thought**](#chain-of-thought) | Forces stepwise reasoning |
| Edge-case heavy tasks | [**Few shot (2-5 samples)**](#one-shot--few-shot) | Covers exceptions & rare labels |
| Mission-critical accuracy | [**Guided CoT + Self Consistency**](#guided-cot--self-consistency) | Multiple reasoned paths to a consensus |
| Tool-use / knowledge-heavy tasks | [**ReAct (Reasoning + Acting)**](#react-reasoning-and-acting) | Thinks, calls tools, repeats for grounded solutions.  |
| Concise yet comprehensive summarization | [**Chain of Density (CoD)**](#chain-of-density-cod) | Stepwise compression keeps essentials, cuts fluff. |
| Accuracy-critical facts | [**Chain of Verification (CoVe)**](#chain-of-verification-cove) | Asks and answers its own checks, then fixes. |

## Customer Support Ticket Processing Use Case

Throughout this guide, we'll use the practical example of automating customer support ticket processing. This enterprise-relevant use case demonstrates how different prompt patterns can improve:
 - Initial ticket triage and categorization
 - Issue urgency assessment
 - Information extraction from customer communications
 - Resolution suggestions and draft responses
 - Ticket summarization for team handoffs

Using AI to enhance support ticket processing can reduce agent workload, accelerate response times, ensure consistent handling, and enable better tracking of common issues. Each prompt pattern offers distinct advantages for specific aspects of the support workflow.

## Zero Shot

Zero shot prompting tells a large-language model **exactly what you want without supplying a single demonstration**. The model leans on the general-purpose knowledge it absorbed during pre-training to infer the right output. You provide instructions but no examples, allowing the model to apply its existing understanding to the task.

### When to use

| Use case | Why Zero Shot works |
| --- | --- |
| **Sentiment classification** | Model has seen millions of examples during training; instructions suffice |
| **Basic information extraction** (e.g., support ticket triage) | Simple extraction of explicit data points requires minimal guidance |
| **Urgent support ticket assessment** | Clear indicators of urgency are typically explicit in customer language |
| **Standard content formatting** | Straightforward style adjustments like formalization or simplification |
| **Language translation** | Well-established task with clear inputs and outputs |
| **Content outlines and summaries** | Follows common structural patterns; benefits from brevity |

### Support Ticket Zero Shot Example

This example demonstrates using zero shot prompting to quickly analyze a customer support ticket for essential information.

## One Shot & Few Shot

A **one shot prompt** includes exactly one worked example; a **few shot prompt** provides several (typically 3-8) examples. Both rely on the model's in-context learning to imitate the demonstrated input to output mapping. Because the demonstrations live in the prompt, you get the benefits of "training" without fine-tuning: you can swap tasks or tweak formats instantly by editing examples.

### When to use

| Use case | Why One/Few Shot works |
| --- | --- |
| **Structured output (JSON, SQL, XML)** | Examples nail the exact keys, quoting, or delimiters you need |
| **Support ticket categorization** with nuanced or custom labels | A few examples teach proper categorization schemes specific to your organization |
| **Domain-specific extraction** from technical support tickets | Demonstrations anchor the terminology and extraction patterns |
| **Edge-case handling** for unusual tickets | Show examples of tricky inputs to teach disambiguation strategies |
| **Consistent formatting** of support responses | Examples ensure adherence to company communication standards |
| **Custom urgency criteria** based on business rules | Examples demonstrate how to apply organization-specific Service Level Agreement (SLA) definitions |

### Support Ticket Few Shot Example

This example demonstrates using few shot prompting to extract detailed, structured information from support tickets according to a specific schema.

## Chain of Thought

Chain of Thought (CoT) is a prompt engineering technique that explicitly instructs the model to think through a problem step-by-step before producing the answer. In its simplest form you add a phrase like **"Let's think step by step."** This cue triggers the model to emit a sequence of reasoning statements (the "chain") followed by a conclusion. Zero shot CoT works effectively on arithmetic and commonsense questions, while few shot CoT supplies handcrafted exemplars for more complex domains.

### When to use

| Problem type | Why CoT helps |
| --- | --- |
| **Math & logic word problems** | Forces explicit arithmetic steps |
| **Multi-hop Q&A / retrieval** | Encourages sequential evidence gathering |
| **Complex support ticket analysis** | Breaks down issue diagnosis into logical components |
| **Content plans & outlines** | Structures longform content creation |
| **Policy / safety analysis** | Documents each step of reasoning for transparency |
| **Ticket priority determination** | Systematically assesses impact, urgency, and SLA considerations |

### Support Ticket Chain of Thought Example

This example demonstrates using CoT to systematically analyze a customer support ticket to extract detailed information and make reasoned judgments about the issue.

## Guided CoT & Self Consistency

Guided CoT provides a structured outline of reasoning steps for the model to follow. Rather than letting the model determine its own reasoning path, you explicitly define the analytical framework.

<br />

Self-Consistency replaces standard decoding in CoT with a sample-and-majority-vote strategy: the same CoT prompt is run multiple times with a higher temperature, the answer from each chain is extracted, then the most common answer is returned as the final result.

### When to use

| Use case | Why it works |
| --- | --- |
| **Support ticket categorization** with complex business rules | Guided CoT ensures consistent application of classification criteria |
| **SLA breach determination** with multiple factors | Self-Consistency reduces calculation errors in deadline computations |
| **Risk assessment** of customer issues | Multiple reasoning paths help identify edge cases in potential impact analysis |
| **Customer sentiment analysis** in ambiguous situations | Consensus across multiple paths provides more reliable interpretation |
| **Root cause analysis** for technical issues | Guided steps ensure thorough investigation across all system components |
| **Draft response generation** for sensitive issues | Self-Consistency helps avoid inappropriate or inadequate responses |

## ReAct (Reasoning and Acting)

ReAct (Reasoning and Acting) is a prompt pattern that instructs an LLM to generate two interleaved streams:

1. **Thought / reasoning trace** - natural-language reflection on the current state
2. **Action** - a structured command that an external tool executes (e.g., `Search[query]`, `Calculator[expression]`, or `Call_API[args]`) followed by the tool's observation

Because the model can observe the tool's response and continue thinking, it forms a closed feedback loop. The model assesses the situation, takes an action to gather information, processes the results, and repeats if necessary.

### When to use

| Use case | Why ReAct works |
| --- | --- |
| **Support ticket triage requiring contextual knowledge** | Enables lookup of error codes, known issues, and solutions |
| **Ticket analysis needing real-time status checks** | Can verify current system status and outage information |
| **SLA calculation and breach determination** | Performs precise time calculations with Python execution |
| **Customer history-enriched responses** | Retrieves customer context from knowledge bases or documentation |
| **Technical troubleshooting with diagnostic tools** | Runs diagnostic scripts and interprets results |
| **Product-specific error resolution** | Searches documentation and knowledge bases for specific error codes |

## Chain of Verification (CoVe)

Chain of Verification (CoVe) prompting turns the model into its own fact-checker. It follows a four-phase process: first writing a draft analysis, then planning targeted verification questions, answering those questions independently to avoid bias, and finally producing a revised, "verified" response. This technique can reduce error rates significantly across knowledge-heavy tasks while adding only one extra round-trip latency.

### When to use

| Use case | Why CoVe works |
| --- | --- |
| **Support ticket categorization auditing** | Verifies proper categorization through targeted questions |
| **SLA calculation verification** | Double-checks time calculations and policy interpretation |
| **Technical troubleshooting validation** | Confirms logical connections between symptoms and causes |
| **Customer response quality assurance** | Ensures completeness and accuracy of draft responses |
| **Incident impact assessment** | Validates estimates of business impact through specific questions |
| **Error code interpretation** | Cross-checks error code explanations against known documentation |

## Chain of Density (CoD)

Chain of Density (CoD) is an iterative summarization technique that begins with a deliberately entity-sparse draft and progressively adds key entities while maintaining a fixed length. In each round, the model identifies 1-3 new entities it hasn't mentioned, then rewrites the summary: compressing existing text to make room for them. After several iterations, the summary achieves a higher entity-per-token density, reducing lead bias and often matching or exceeding human summaries in informativeness.

### When to use

| Use case | Why CoD works |
| --- | --- |
| **Support ticket executive summaries** | Creates highly informative briefs within strict length limits |
| **Agent handover notes** | Ensures all critical details are captured in a concise format |
| **Knowledge base entry creation** | Progressively incorporates technical details without increasing length |
| **Customer communication summaries** | Balances completeness with brevity for customer record notes |
| **SLA/escalation notifications** | Packs essential details into notification character limits |
| **Support team daily digests** | Summarizes multiple tickets with key details for management review |

---

## Prompting: Seed (js)