Tharushi de Silva had been using an AI assistant for three months before she discovered she had been doing the same thing every time: typing a question and hoping for the best. When a colleague showed her a different approach, assigning the AI a specific role before asking the question, the output quality jumped so noticeably that she spent the next afternoon testing every variation she could think of. "I was using maybe 20% of what the tool could do," she said afterwards. "And I didn't know there was another 80%." What she was discovering were prompting patterns: structural approaches that reliably improve AI output across a wide range of tasks. This lesson teaches four of them one at a time, because combining them well depends on understanding what each contributes on its own.

What Prompting Patterns Are

A prompting pattern is a structural approach to framing a request that predictably improves the quality of the model's response. Patterns are not magic words or secret codes. They work because they match the way language models process information, which is why they hold up across different tasks, domains, and tools rather than being tricks that stop working when the vendor ships an update.

Two analogies make the idea concrete. The first comes from professional writing: a legal memo follows a pattern, issue then rule then application then conclusion, because that structure produces clear, defensible reasoning, while a data brief follows a different one. Neither format is magic; both organise information in ways that help the reader, or in this case the model, think clearly. The second comes from software engineering. Just as certain design patterns, the observer pattern, the factory pattern, the decorator pattern, solve recurring problems in code, certain prompting patterns solve recurring problems in getting good results from a model.

Patterns are also composable. You do not need to choose just one: a single production prompt often combines role-playing, few-shot examples, and chain-of-thought reasoning at once. The skill is not knowing the patterns, it is knowing which combination a specific task needs, and that is much easier to develop if you learn each building block in isolation first.

Pattern 1: Role Assignment

Role assignment, also called persona prompting or character adoption, means telling the model what kind of expert it should behave as before it addresses your question. Instead of "What are the risks of this contract clause?" you ask "You are an experienced commercial lawyer specialising in technology contracts. What are the risks of this clause?" Instead of "Summarize this technical paper," you ask "You are a researcher writing this for a general audience. Summarize this technical paper." The model anchors to the role and adjusts its language, depth, and perspective accordingly.

The mechanism tells you when the pattern will help. The model has been trained on an enormous range of text, so assigning a role filters its response toward the vocabulary, reasoning style, and knowledge domain of that role. Different roles carry different communication styles, knowledge levels, assumptions, and priorities, and specifying one narrows an effectively infinite range of answers to the region you need. A senior financial analyst's answer to a cash flow question will use different framing, different assumptions, and different caution flags than a general assistant's answer to the same question.

Roles work best when they are specific. "Expert" is too vague to filter anything, while "Senior compliance officer at a UK financial services firm" produces noticeably better results on regulatory questions than "compliance expert," because domain, seniority, and organisational context each narrow the response further. Use the pattern whenever you want output in a particular voice: teaching a complex concept to beginners, generating business-focused advice, creating content in a genre, or working through a technical problem as an experienced engineer would.

Three worked examples show the range. For teaching: "You are a computer science professor teaching this concept to undergraduate students who have not taken calculus. Explain neural networks without using mathematical notation." For business advice: "You are a venture capitalist with 20 years of startup experience. What are the top three risks with this business plan?" For creative work: "You are a science fiction author known for hard science and realistic worldbuilding. Write a 500-word scene where humans encounter an alien species for the first time." Each names a role, a context, and an audience or constraint. Tharushi uses the same shape routinely: drafting communications for her CEO, she opens with "You are a senior communications director with experience writing for a C-suite audience in the technology sector," and the tone difference is visible in the first paragraph of the output.

Pattern 2: Few-Shot Examples

Few-shot learning means giving the model a small number of examples of the output you want before asking it to produce one for your actual task. Rather than describing the format, you show it. The name comes from AI research, where "zero-shot" means no examples and "few-shot" means a handful, typically two to five. It works because patterns are easier to infer from examples than from description, and a single example of well-formatted output is worth a great deal of explanation about formatting. For most professional tasks three well-chosen examples are enough; more than five rarely improves results and makes the prompt unwieldy.

Few-shot earns its place when the task is easier to show than describe: formatting, classification, transformation, style replication, and domain-specific conventions that would take a paragraph to spell out. It is also the right fix when the model's default output is close but consistently wrong in one specific way, because a couple of examples that get that detail right correct the drift faster than an instruction telling it not to drift.

Here is the pattern on a formatting problem: converting product reviews into a structured summary, with two examples before the real input.

• Convert these product reviews into a structured format:
• Example 1: Input: "The laptop is fast but runs hot and the battery only lasts 3 hours"
• Output: Pros: Fast | Cons: Runs hot, short battery life
• Example 2: Input: "Love the design, hate the keyboard, price is reasonable"
• Output: Pros: Good design, reasonable price | Cons: Poor keyboard
• Now convert this review: "Amazing screen quality, heavy to carry, no USB-C"

The same shape works for classification, where the examples teach category boundaries rather than a layout. A support-ticket triage prompt supplies labelled tickets before the one you care about: Ticket: "My account is locked and I can't access my data" / Classification: Critical, then Ticket: "How do I change my password?" / Classification: Low, then Ticket: "The app crashes when I click the export button" / Classification: High, before asking it to Classify this: "The UI looks different since the update, is it a bug?" No definition of "critical" appears anywhere in that prompt. The examples do the defining, and more precisely than a definition would, because the hard part of triage is the boundary cases rather than the concept.

Tharushi's own use illustrates the before and after. Her zero-shot prompt for turning customer feedback into action items was "Convert this customer feedback into a structured action item," and the results were inconsistent in format, varied in specificity, and often omitted the responsible team. Her few-shot version keeps the instruction and adds two demonstrations: Feedback: 'The invoice portal crashes when I upload PDFs' → Action: Fix PDF upload stability in invoice portal | Owner: Engineering | Priority: High, and Feedback: 'Response times are slow' → Action: Investigate support ticket response time SLA | Owner: Customer Success | Priority: Medium, followed by Now convert: [actual feedback]. The few-shot version produces consistent, structured output on the first attempt, with no follow-up prompt needed. The model learns format from examples better than it learns it from descriptions of format.

Pattern 3: Chain of Thought

Chain-of-thought prompting asks the model to show its reasoning step by step before delivering a conclusion. You trigger it with phrases such as "Think through this step by step before answering," "Walk me through your reasoning," or "First analyse the factors, then give your recommendation." The change to the prompt is small; the effect on accuracy is large, particularly on tasks involving reasoning, logic, mathematics, or multi-factor analysis.

Why it works is not mysterious. When the model generates reasoning steps, each becomes part of the context for the next, so the answer is built on stated intermediate results rather than produced in a single leap. That gives the model room to catch its own errors, and gives you something to inspect: mistakes in the chain become visible instead of hiding inside a confident conclusion. It mirrors how people handle hard problems, working through the steps rather than intuiting the answer, and it is most valuable exactly where intuition is least reliable.

Use it for complex reasoning, multi-step problems, mathematical or logical analysis, decisions with several competing factors, any situation where accuracy is critical, and any situation where you want to understand how the model reached its position rather than simply receiving it. Three examples show how little scaffolding is needed. A quantitative one: "Q: If a store raises prices by 20% and then runs a 10% off sale, what is the net price change? Think through this step-by-step." A judgement call: "Should we acquire this startup? Consider: technology, team, market fit, financials, and competitive position. Work through each factor before giving your final recommendation." A diagnostic one: "Why might this code be throwing an error? Walk through the execution flow and identify where the problem likely occurs."

The contrast is starkest on real business decisions. A direct prompt such as "Should we expand our support team before adding new product features?" tends to produce a conclusion resting on assumptions the model never states. The chain-of-thought version specifies the reasoning path: "Think through this step by step. First, what are the current support team capacity indicators? Second, what does planned feature development typically do to support ticket volume? Third, what is the risk of adding feature load before addressing support capacity? Fourth, given these considerations, what would you recommend and why?" The second version is longer, and it produces reasoning you can scrutinise. You can see where the logic holds, where an assumption was smuggled in, and where you disagree, which turns the output into a thinking partner rather than an oracle.

Pattern 4: Step-by-Step Instructions

Where chain-of-thought asks the model to reason step by step, step-by-step instructions tell the model which steps to follow when producing the output. You specify the process, not just the outcome. The distinction is easy to blur and worth keeping sharp: chain-of-thought makes the thinking visible before an answer, while step-by-step decomposition sets the actual sequence of work the model performs to build the deliverable.

This is the pattern for tasks that naturally break into stages, for comprehensive content generation, for structured workflows, and for anything where completeness matters more than elegance. It is also the pattern for a known process you want followed consistently: a standard operating procedure, a review checklist, a defined analysis framework. You prescribe the approach rather than letting the model choose one, which is what makes outputs comparable across many runs.

A contract review shows the effect. "Review this supplier contract following these steps in order: (1) Identify all payment terms and flag any that deviate from net-30 standard. (2) List all exclusivity clauses. (3) Identify all liability caps and assess whether they are symmetrical. (4) Flag any automatic renewal clauses. (5) Summarise the three most significant commercial risks." The output is structured exactly around those steps: predictable, complete, and easy to compare across a stack of contracts. The model will not skip a step or reorder them, so if your review process depends on a particular sequence, this pattern enforces it.

The same shape applies well outside legal review. For content: Write a blog post about remote work productivity. Follow this process: Step 1: Write a compelling headline. Step 2: Write an engaging introduction. Step 3: Develop three main points (one section each). Step 4: Write a conclusion that summarizes and provides actionable advice. Step 5: Review and improve any section that feels weak. For planning: Create a plan to launch a new feature. Follow this process: Step 1: Define success metrics and goals. Step 2: Identify stakeholders and their concerns. Step 3: Create a timeline with milestones. Step 4: Identify risks and mitigation strategies. Step 5: Plan for launch day activities. Step 6: Plan for post-launch monitoring. In both cases the final step does work the model would otherwise skip, which is the quiet benefit of the pattern: you can require the review, the risk pass, or the monitoring plan that a single open-ended instruction leaves out.

Combining Patterns

Experienced practitioners rarely use one pattern in isolation. Tharushi's monthly supplier review prompt opens with a role assignment (senior procurement analyst), specifies four review steps (step-by-step instructions), asks the model to think through causes before recommending actions (chain of thought), and includes one prior review as a format example (few-shot). It takes two minutes to assemble and produces output she can send with minimal editing. Each pattern adds a different dimension of control, so they stack cleanly.

A worked combined prompt makes the layering visible. Consider an analysis of user interview notes. It opens with the role: You are an experienced user experience researcher. You conduct user interviews and synthesize insights. It then supplies a format example, which is the few-shot layer: Interview notes format example: User: "Product is confusing" / Insight: Navigation is non-intuitive / Quote: "I couldn't find the settings menu". Next comes the process, which is the step-by-step layer, introduced with Analyze these interview notes following this process: and then these steps in order:

• Extract key themes from all interviews
• Identify the strongest signal (most mentioned issues)
• For each major theme, provide supporting quotes
• Assess impact: how many users were affected?
• Recommend one high-impact improvement

Finally the chain-of-thought layer is applied to the one part of the output where reasoning matters most: For the recommendation, explain your reasoning. That last line is the detail most people miss. You do not have to apply chain-of-thought to the whole prompt; applying it to the single step that carries a judgement gives you reasoning you can challenge without burying the structured output underneath a wall of deliberation.

Choosing the Right Pattern

Choosing between patterns is a question about the task, not about the model. Ask what is missing from the output you keep getting, then reach for the pattern that supplies it.

Between them these four cover the large majority of prompting needs, which is why they are worth treating as building blocks rather than as a list of tips. Role-playing anchors perspective, few-shot provides examples, chain-of-thought enables reasoning, and step-by-step ensures completeness.

Anti-Patterns

The failure modes are consistent enough to name. The most common is the vague role: writing "You are an expert" and expecting the benefit that only comes from naming a domain, a seniority, and a context. A second is piling on examples on the theory that if a few help then many more will help further; past five they rarely improve results and start making the prompt unwieldy. A third is few-shot examples that are all the same case, which teaches the model your layout but nothing about the boundaries you care about.

Two more come from confusing the reasoning patterns. Chain-of-thought where you needed a prescribed process leaves the model free to choose its own path, so outputs stop being comparable between runs. Step-by-step instructions on a genuinely open analytical question force the model down a path you invented before you understood the problem. The last anti-pattern is treating a pattern as a guarantee: patterns raise the probability of good output, they do not verify it, and exposed reasoning helps only if somebody reads it.

Practice Prompts

Work through these with a task from your own week rather than an invented one; the value is in comparing outputs you are qualified to judge.

• Take a task you do regularly. Write two prompts for it, one using role assignment and one using few-shot examples, then compare the results and decide which pattern the task actually needed.
• Write a single prompt that uses all four patterns in combination, and after reading the output, identify what each pattern contributed.
• Take a prompt that is producing mediocre results. Diagnose which pattern is missing rather than rewriting the wording, then add only that pattern and re-run it.
• Convert one prescribed process from your team, a review checklist or standard operating procedure, into a numbered step-by-step prompt that ends with a quality pass.

Reflection

Sort the prompts you sent this week into two piles: the ones where you accepted the first output, and the ones where you argued with the model for several rounds. The second pile is where patterns pay for themselves, and it is usually the pile where you never told the model who it was supposed to be, never showed it the format you wanted, and never asked it to show its working. Pick the most expensive recurring task in that pile and ask what a properly built prompt would need to contain to produce sendable output first time.

Glossary

• Prompting pattern: a structural approach to framing a request that predictably improves output quality, grounded in how language models process information rather than in particular wording.
• Role assignment (persona prompting, character adoption): instructing the model to respond as a specified kind of expert, which filters its response toward that role's vocabulary, assumptions, and reasoning style.
• Zero-shot: a prompt that describes the task without providing any examples of the desired output.
• Few-shot learning: supplying a small number of examples, typically two to five, so the model infers the pattern from demonstration and applies it to new cases.
• Chain of thought: asking the model to show its reasoning step by step before giving a final answer, making intermediate steps visible and checkable.
• Step-by-step instructions (process decomposition): specifying the sequence of steps the model should follow to produce the output, prescribing the process rather than only the outcome.

Related Lessons

Anatomy of an Effective Prompt covers the components a single prompt needs before any pattern is applied to it. Chain-of-Thought & Reasoning Prompts goes deeper on the third pattern here, including where explicit reasoning helps least. Iterative Refinement picks up where this lesson stops, at the point where a patterned prompt is close but not yet right. Building a Personal Prompt Testing Workflow is the natural next step once you have prompts worth reusing, because a combined four-pattern prompt is an asset that deserves version control and comparison.

Closing

The four patterns are not a checklist to run on every request. Most quick questions need none of them. Their value shows up on recurring, consequential tasks: the weekly report, the standard review, the analysis somebody will decide on. For those, identify the pattern that fixes what is missing, apply it alone until you can see its contribution, then layer the others on and keep the prompts that earn their keep. The best prompts rarely use just one pattern; they combine patterns deliberately to get exactly the output the task requires.

Key Takeaways

• Prompting patterns work because they match how language models process information. They are not tricks or magic words, which is why they transfer across tasks, domains, and tools.
• Role assignment filters the model toward a specific expertise and communication style. Domain, seniority, and organisational context amplify the effect; "expert" on its own filters nothing.
• Few-shot examples teach format, tone, and category boundaries faster than descriptions do. Three well-chosen examples typically outperform a paragraph about formatting, and more than five rarely helps.
• Chain-of-thought prompting makes reasoning visible and verifiable. Use it when the task requires multi-step logic and you need to judge whether a conclusion is sound rather than whether it sounds plausible.
• Step-by-step instructions enforce a prescribed process. Use them when a defined workflow must be followed consistently, and make the quality pass an explicit final step.
• Patterns are designed to be combined, including partially. Applying chain-of-thought to only the step that carries a judgement keeps the reasoning available without burying the structured output.
• A good combined prompt pays for itself quickly. One that takes ten minutes to build properly and then produces near-final output on a weekly task saves hours of editing over a month.

Frequently Asked Questions

What is few-shot learning in prompting? It means providing a few examples of the task you want performed rather than only describing it. Instead of saying "Convert sentences to questions," you show a small number of sentences converted to questions and let the model infer the pattern before applying it to your real input. The examples carry information that is hard to state, particularly formatting conventions and the boundaries between categories.

How many examples do I need? Two to five is the normal range, and three well-chosen examples are enough for most professional tasks. A single example gives little guidance about which of its features matter, while a long list makes the prompt unwieldy without improving output. Choose examples that differ in ways that matter, because their job is to mark the boundaries of the task rather than repeat the same case.

When should I use chain-of-thought prompting? Use it for complex reasoning, multi-step problems, mathematical or logical analysis, decisions involving several competing factors, and any task where accuracy is critical or you need to inspect the model's thinking. Asking it to work through the problem step by step produces more reliable results on exactly the tasks where a fluent-sounding wrong answer is hardest to spot.

What is the difference between chain-of-thought and step-by-step instructions? Chain-of-thought asks the model to show its reasoning before answering and leaves the path open. Step-by-step instructions specify the process the model must follow to produce the output. Use the first when the task is analytical and you want to evaluate the thinking; use the second when the process is defined and you need it followed the same way every time.