1 Overview

The previous tutorial gave you the anatomy of a single good prompt. Real development work, though, is rarely one prompt — it is a conversation with structure. Experienced developers do not improvise that structure each time; they reach for a small set of named, repeatable recipes. This tutorial catalogs those recipes: the prompting patterns that turn a capable model into a dependable working partner.

You will learn five patterns that cover most day-to-day development interaction: Ask → Review → Improve (the fundamental quality loop), Explain → Generate → Refine (alignment before production), step-by-step chain-of-thought prompting (for problems that need reasoning), prompt sequences (decomposing big requirements into verifiable stages), and the debugging pattern (structured error analysis). Each pattern comes with the why, the mechanics, C# examples, and the failure modes to watch for.

A prompting pattern is to prompts what a design pattern is to classes: not a rigid rule, but a proven shape you adapt. Once these five are in your muscle memory, you will notice that most 'the model gave me garbage' complaints trace back to skipping a pattern step — usually the review.

2 Learning Objectives

After completing this tutorial, you will be able to:

• Explain what a prompting pattern is and why patterns beat improvised prompting.
• Run the Ask → Review → Improve loop with explicit acceptance criteria and targeted improvement requests.
• Apply Explain → Generate → Refine to align the model's understanding before it produces code.
• Use step-by-step chain-of-thought prompting for problems that require multi-step reasoning, and know its costs.
• Break a complex requirement into a prompt sequence whose stages are individually verifiable.
• Prompt effectively for debugging and error analysis: what to include, what to withhold, and how to verify proposed causes.
• Implement multi-turn pattern conversations in C# with proper conversation history management.
• Choose the right pattern (or combination) for a given development task.

3 Prerequisites

• Tutorial 2 (Foundations of Prompt Engineering) — prompt anatomy, iteration, zero/few-shot styles, output validation.
• Tutorial 1 concepts: tokens, context window, hallucination, system vs user messages.
• Comfortable intermediate C#: async/await, collections, exceptions, and reading stack traces.
• Any chat model to practice with; the C# samples show how patterns become application code.

4 What Prompting Patterns Are and Why They Work

A prompting pattern is a reusable interaction recipe: a named sequence of prompts, checks, and follow-ups that reliably produces good results for a class of tasks. Patterns exist because single-shot prompting has a ceiling — even a perfectly written prompt gets a probabilistic first draft, and first drafts are where quality problems live. Patterns wrap the model's raw generation in structure: verification points, alignment steps, and decomposition.

Patterns work for three reasons. First, they impose checkpoints: every pattern has at least one moment where a human (or validating code) judges output against acceptance criteria before it moves forward. Second, they manage context deliberately: each step's prompt carries exactly the information that step needs — verified output from earlier steps, not raw hope. Third, they match the model's strengths: models are excellent at focused transformations and explanations, and weaker at giant, under-specified, do-everything requests.

The patterns compose. A prompt sequence's individual stages each run Ask → Review → Improve; a debugging session often opens with Explain (have the model restate the failing behavior) and uses chain-of-thought for the causal reasoning. They also combine freely with the styles from the previous tutorial — few-shot prompting can teach a stage's output format, and grounding supplies its facts. Treat the five as a toolkit, not as five separate ceremonies.

5 The Ask → Review → Improve Pattern

Ask → Review → Improve is the fundamental quality loop, and the discipline is almost entirely in the second and third steps. Ask: request the output with full prompt anatomy — instruction, context, input data, output constraints — and, crucially, know your acceptance criteria before you ask. Review: read the output critically against those criteria; for code that means correctness, edge cases, naming, error handling, and fit with your codebase — not 'does it look plausible'. Improve: instead of re-rolling the whole request, name the specific deficiencies and ask for targeted fixes.

Two refinements make the loop sharper. First, targeted improvement requests beat regeneration: 'add null handling for the customer parameter and make the method async' converges in one turn, while 'try again' just re-rolls the dice. Second, use model self-review as a pre-filter: 'Review the code you just wrote against these criteria: … List any violations before I do.' The model catches many of its own mechanical misses — but self-review supplements your review, it never replaces it, because the model grades its own work with the same blind spots that produced it.

6 The Explain → Generate → Refine Pattern

Explain → Generate → Refine tackles a different risk: the model producing confident output from a wrong understanding. Before asking for any production output, you first ask the model to explain — restate the requirement in its own words, or walk through what the existing code actually does. You verify that explanation. Only then does it generate, and afterwards you refine as usual.

The Explain step is cheap insurance. If the model misreads your requirement ('rolling 30-day window' understood as 'calendar month'), you catch it in a two-sentence explanation instead of in 80 lines of confidently wrong code. And when modifying existing code, Explain doubles as grounding: a model that has just correctly traced your method's behavior is dramatically less likely to break it while changing it. The pattern shines for legacy code changes, ambiguous tickets, and any task where the cost of misunderstanding is high.

• Explain: 'Before writing anything, explain in your own words what this method does and what I am asking you to change.'
• Verify: read the explanation; correct any drift — 'point 2 is wrong: the discount applies before tax, not after.'
• Generate: 'Correct. Now make the change, preserving current behavior for all other paths.'
• Refine: run the Ask → Review → Improve loop on what came back.

7 Step-by-Step (Chain-of-Thought) Prompting

Chain-of-thought prompting asks the model to reason step by step before committing to an answer: 'Think through this step by step, then give your conclusion.' Because generation is sequential, the intermediate reasoning tokens become context that conditions the final answer — the model effectively shows its work and then answers from that work, which measurably improves results on multi-step logic: boundary conditions, date arithmetic, concurrency interleavings, 'what does this query return when the join is empty'.

Use chain-of-thought deliberately, not universally. It costs tokens and latency (all that reasoning is billed output), and for simple lookups or formatting tasks it adds nothing. It earns its cost on reasoning-heavy questions — and it pairs beautifully with debugging (section 10) and with review steps ('walk through this code path step by step for the case where the list is empty'). Two caveats: the written reasoning is itself model output, so a step can be wrong while sounding rigorous — inspect it; and some newer models perform internal reasoning on their own, making explicit step-by-step instructions less necessary — test with your model rather than assuming.

8 Breaking Complex Requirements into Prompt Sequences

Some tasks are simply too big for one prompt: 'build the invoicing module' stuffed into a single request produces a sprawling, unreviewable draft with hallucinated pieces. The prompt sequence pattern applies standard engineering decomposition to prompting: split the requirement into stages, prompt each stage separately, verify each output, and feed verified outputs forward as context for the next stage.

Decomposition brings three concrete wins. Reviewability: a 30-line interface proposal is checkable in a minute; a 400-line module dump is not. Error containment: a mistake caught at the design stage costs one correction, not a cascade. Context control: each prompt carries only what its stage needs, staying well inside the context window even for large features. The standard stage sequence for a feature — design → implementation → tests → documentation — mirrors how you would review a colleague's work, which is not a coincidence.

Manage the sequence's context deliberately: pass forward the verified artifacts (the approved interface, the corrected code), not the full transcript of every turn. Summarize decisions between stages when the conversation history grows. In application code, each stage is often a separate API call with a purpose-built prompt template rather than one long chat — you control exactly what context each stage sees.

9 Where Patterns Live in the .NET Ecosystem

These patterns are tool-agnostic — the same shapes work in a chat window, in GitHub Copilot, and in your application code — but each surface has its own mechanics:

• Interactive chat (Azure AI Foundry playground, any chat UI): patterns are conversational turns; you are the review step. Ideal for practicing the loop before encoding it.
• GitHub Copilot Chat in Visual Studio / VS Code: patterns map to threaded conversations with your code in context — Explain → Generate → Refine is Copilot's natural gait for modifying existing files (tutorials 8–9 go deep).
• Application code via Azure OpenAI: patterns become orchestrated API calls — a multi-turn conversation is a list of messages your C# code builds, and each pattern step is a message (or a separate call) with conversation history you explicitly manage.
• Semantic Kernel (tutorials 17–18): patterns formalized — prompt templates per stage, function chaining for sequences, and planners that decompose goals automatically.
• Prompt templates in your repository: each pattern step that your application runs unattended (a review prompt, a debugging prompt) should be a versioned prompt template with its own test inputs.

One mechanical point matters everywhere: models are stateless. A 'conversation' exists only because every request replays the conversation history. That is why patterns that span turns (all five here) are also token-budget decisions — history you replay is context you pay for, so the pattern step that summarizes or trims history is part of the engineering, not an optimization afterthought. Standing rules belong in the system message, where they survive every turn without being repeated.

10 The Debugging Pattern: Prompting for Error Analysis

Debugging is the pattern developers reach for most often under pressure, and the one where prompt quality changes outcomes most dramatically. The model cannot attach a debugger — it reasons only from the evidence you provide. Structured error analysis means assembling that evidence deliberately:

• The exact error message and the full stack trace — verbatim, not paraphrased.
• The relevant code — ideally a minimal reproduction rather than the whole file; trimming noise focuses the analysis and fits the context window.
• Expected vs actual behavior, stated precisely: 'expected 3 rows, got 0' beats 'it doesn't work'.
• Environment facts that matter: framework version, database, concurrency, recent changes.
• What you already tried and what it ruled out — this prunes the model's search space.

Then ask for ranked hypotheses, not a single verdict: 'List the most likely root causes in order of probability, and for each, tell me what evidence would confirm or rule it out.' This framing does two things: it makes the model reason comparatively (chain-of-thought fits naturally here), and it hands you a verification plan instead of a leap of faith. You then check the top hypothesis in the debugger — the model proposes, your tools confirm.

Beyond exceptions, the same shape works for wrong-output bugs ('here is the input, the output, and the transformation code — walk through step by step where the value diverges'), performance mysteries (provide the profile numbers), and flaky tests (provide the failure frequency and both passing and failing logs). In every variant, the quality of the analysis tracks the quality of the evidence — garbage in, confident garbage out.

11 Code Examples in C#

Patterns in application code are conversations your program conducts. This example runs Ask → Review → Improve as a multi-turn conversation, using model self-review as the middle step (illustrative SDK usage — see section 13):

// The conversation history IS the state — the model itself is stateless.
List<ChatMessage> history =
[
    new SystemChatMessage(
        "You are a careful C# engineer. Follow the acceptance criteria exactly."),

    // --- ASK ---
    new UserChatMessage(
        """
        Write a C# extension method 'Chunk<T>' that splits an IEnumerable<T>
        into lists of a given size.
        Acceptance criteria: lazy evaluation; last chunk may be short;
        throw ArgumentOutOfRangeException for size < 1; include XML docs.
        """)
];

ChatCompletion draft = await chat.CompleteChatAsync(history);
history.Add(new AssistantChatMessage(draft.Content[0].Text));

// --- REVIEW (model self-review first, human review still follows) ---
history.Add(new UserChatMessage(
    "Review your code against each acceptance criterion. " +
    "List any violations or edge cases you missed. Do not rewrite yet."));
ChatCompletion review = await chat.CompleteChatAsync(history);
history.Add(new AssistantChatMessage(review.Content[0].Text));

// --- IMPROVE (targeted, based on the review) ---
history.Add(new UserChatMessage(
    "Fix every issue you listed. Output only the corrected code."));
ChatCompletion final = await chat.CompleteChatAsync(history);

Console.WriteLine(final.Content[0].Text); // now goes to HUMAN review + tests

The debugging pattern makes an excellent prompt template — the structure is fixed, only the evidence changes:

public static class DebugPrompts
{
    // v2: added 'already tried' and ranked-hypotheses framing (2026-09).
    public static string BuildErrorAnalysisPrompt(
        string errorMessage, string stackTrace, string minimalRepro,
        string expectedVsActual, string alreadyTried) => $"""
        Analyze this .NET error.

        Error message:
        {errorMessage}

        Stack trace:
        {stackTrace}

        Minimal reproduction:
        ```csharp
        {minimalRepro}
        ```

        Expected vs actual: {expectedVsActual}
        Already tried (ruled out): {alreadyTried}

        Reason step by step, then list the most likely root causes
        ranked by probability. For each: what evidence would confirm
        or rule it out. Do not propose fixes yet.
        """;
}

Note the last line: separating diagnosis from fixing is deliberate. You confirm the root cause first (the pattern's review step), then request the fix in a follow-up turn — carrying the confirmed diagnosis forward as verified context, exactly like a prompt sequence stage.

12 Step-by-Step: A Full Debugging Session with the Patterns

This walkthrough combines four of the five patterns on a realistic bug: an ASP.NET endpoint intermittently returns stale data after an update. Follow the same shape on your next real bug.

1. Gather evidence first (debugging pattern): the exact symptom ('GET returns the old value for up to 30 seconds after PUT succeeds'), the controller and repository code trimmed to a minimal reproduction, the cache configuration, and what you ruled out (database write confirmed immediate).
2. Open with Explain: paste the minimal reproduction and ask the model to explain what the code does — no diagnosis yet. Verify its reading matches reality; correct any drift.
3. Ask for ranked hypotheses with chain-of-thought: 'Reason step by step, then rank likely root causes; for each, what evidence confirms or rules it out.' Suppose it ranks: (1) cache not invalidated on update, (2) distributed cache replication lag, (3) response caching middleware.
4. Verify before fixing: check hypothesis 1 in the code — the update path indeed never evicts the cache key. The model proposed; your inspection confirmed. (If inspection had disproved it, you would feed that fact back and re-rank — improving the analysis, not guessing.)
5. Request the fix against the confirmed diagnosis only: 'Root cause confirmed: missing cache eviction on update. Propose the minimal fix; preserve existing behavior for reads.'
6. Review the fix (Ask → Review → Improve): check it against criteria — evicts the right key, no race between eviction and write, no behavior change elsewhere. Ask for targeted improvements if needed.
7. Close the loop with a sequence stage: 'Write a test that fails under the old code and passes with the fix' — regression protection generated while the context is still verified and warm.

13 Limitations and Caveats

• Patterns raise reliability; they do not create guarantees. Every pattern's checkpoint assumes a competent reviewer — the loop is only as strong as your review.
• Chain-of-thought reasoning is itself generated text: a step can be wrong while sounding rigorous, and visible reasoning is not always the model's actual computation. Inspect steps; never treat shown reasoning as proof.
• Multi-turn patterns pay a token tax: replayed conversation history grows every turn and is billed every turn. Summarize or trim between stages; in application code, prefer purpose-built calls per stage over one ever-growing chat.
• Error analysis can hallucinate root causes with high confidence — always run the confirming evidence check before applying a fix.
• Long conversations drift: earlier constraints fade from the model's effective attention. Re-state critical constraints in later turns, or restart with a summary when a session grows long.
• Model behavior varies: newer models with built-in reasoning may need less explicit chain-of-thought; re-test your patterns when the model changes, exactly as you re-test prompts.

14 Best Practices and Common Mistakes

Practices that make the patterns stick:

• Write acceptance criteria before the first Ask — review needs a yardstick.
• Make improvement requests targeted and specific; 'try again' is a wasted turn.
• Use model self-review as a pre-filter, never as the final review.
• Verify the Explain step before allowing generation — it is the cheapest checkpoint you will ever get.
• Reserve chain-of-thought for reasoning-heavy tasks; ask for labeled 'Reasoning:' and 'Answer:' parts when code must parse the result.
• Decompose anything you could not review in one sitting; verify at every stage boundary and pass forward only verified artifacts.
• In debugging, provide verbatim errors, a minimal reproduction, and what you ruled out; demand ranked hypotheses with confirming evidence.

Mistakes that undo the patterns:

• Skipping Review under deadline pressure — the pattern's entire value lives there.
• Regenerating instead of improving: five re-rolls teach the model nothing; one targeted fix converges.
• Letting the model generate against an unverified understanding of your requirement or code.
• Using chain-of-thought everywhere and paying its token cost on trivial tasks.
• One giant prompt for a feature, then trying to review a 400-line dump in one pass.
• Paraphrasing error messages or pasting whole files instead of a minimal reproduction.
• Applying a proposed fix without confirming the diagnosis — the classic hallucinated-root-cause trap.
• Letting conversation history balloon until early constraints silently fall out of effective context.

20 Summary & Key Takeaways

• A prompting pattern is a reusable interaction recipe; patterns beat improvisation because they build in checkpoints, deliberate context management, and task shapes that fit the model.
• Ask → Review → Improve is the default loop: criteria before asking, critical review of every draft, targeted fixes instead of re-rolls. Skipping review is the number-one failure.
• Explain → Generate → Refine buys the cheapest checkpoint available: verify the model's understanding in two sentences before it writes eighty lines.
• Chain-of-thought makes the model reason step by step — the written steps condition the answer. Use it for logic-heavy work, inspect the steps, and budget its token cost.
• Prompt sequences decompose big requirements into verifiable stages: reviewable outputs, contained errors, controlled context. Pass forward artifacts, not transcripts.
• The debugging pattern is evidence engineering: verbatim errors, minimal reproduction, expected-vs-actual, ruled-out attempts — then ranked hypotheses, confirmed before any fix.
• Models are stateless: conversation history is your only memory and a recurring cost — summarize, trim, and re-state critical constraints.
• The patterns compose; scale the ceremony to the task, but never scale it to zero — review is the part that is never optional.

You now have the interaction toolkit that experienced developers bring to every model session. The next tutorial applies these patterns to the specific craft of generating code: idiomatic C#, tests, refactoring, and the coding-task prompt shapes that get production-quality results.

21 Next Steps

Continue with the next tutorial in the path: Prompt Engineering for Coding Tasks — where these patterns meet concrete code generation: scaffolding, refactoring, translating between idioms, and getting C# that fits your codebase rather than a tutorial's.

• Practice: take your next real task and run the full Ask → Review → Improve loop with written acceptance criteria — count how many criteria the first draft actually missed.
• Practice: pick a legacy method you know well, run the Explain step, and grade the model's explanation — then try the same on a method you don't know, and notice the difference in your ability to verify.
• Practice: on your next bug, use the debugging template from section 11 verbatim — including 'no fixes yet' — and verify the top hypothesis before requesting the fix.
• Practice: replay section 12's session shape on a bug from your own backlog, counting your verification checkpoints.
• Reading: Microsoft Learn's prompt engineering guidance on chain-of-thought and conversation design in the Azure OpenAI documentation.