The short version

Examples are one of the most reliable ways to steer Claude's format, tone, and structure. Instead of only describing what a good answer should look like, demonstrate the pattern you want Claude to reproduce. A useful mental model: Instruction → tells Claude the rule.

Editorial analysis

The useful lesson is not a single prompt formula. It is a way to reduce ambiguity: state the outcome, supply only the context that changes the answer, demonstrate the pattern when format matters, and test whether the result remains reliable across several inputs.

A useful way to read this study is as a decision guide: identify the problem it solves, the conditions where it works, the tradeoffs it introduces, and the evidence you would need before relying on it.

Session 3 · Use Examples Effectively

Source article:

Key concept

Examples are one of the most reliable ways to steer Claude's format, tone, and structure. Instead of only describing what a good answer should look like, demonstrate the pattern you want Claude to reproduce.

A useful mental model:

Instruction → tells Claude the rule

Example → shows Claude the rule in action

The article recommends making examples relevant, diverse, and structured, and suggests 3–5 examples for best results.

How it works

Imagine showing a new colleague how you write a project update. You could spend several paragraphs describing your style, or you could show them three excellent updates and say, “Follow this pattern.” The examples make hidden expectations visible.

This does not mean adding random examples. Poor examples can teach the wrong pattern. Your examples should closely resemble the real task, vary enough to cover different situations, and be clearly separated from your instructions.

Practical work example

Task: Turn raw project updates into manager-ready summaries.

Instead of only saying, “Summarize these updates concisely,” give Claude several representative input/output pairs. For example, one could show a normal status update becoming a short progress summary; another could show a blocked project becoming a risk-focused summary; another could show a completed item becoming a decision/action summary.

Claude can infer the recurring pattern: what information matters, what can be omitted, and how the final answer should be shaped.

Weak vs strong prompt

Weak

Summarize these project updates for management.

The model must infer the desired length, structure, level of detail, and what management cares about.

Improved

Convert the project update into a concise manager-ready summary. Follow the patterns demonstrated below.

>

\
\
Input: Data migration completed. Validation found two minor mapping issues. Team expects fixes by Friday.
Output: Migration is complete; two minor mapping issues remain and are expected to be resolved by Friday.
\
\
Input: Vendor has not supplied the API credentials. Integration testing cannot begin. Delivery may slip one week.
Output: Risk: Integration testing is blocked by missing vendor credentials, creating a potential one-week delivery delay.
\
\
Input: Prototype approved. Team needs confirmation on whether to launch to 20 or 50 pilot users.
Output: Decision needed: Confirm whether the approved prototype should launch to 20 or 50 pilot users.
\
\

>

Now summarize the new update using the same principles.

The R-D-S test

Relevant — Does each example closely resemble the real task?

Diverse — Do the examples cover meaningful variations and edge cases?

Structured — Can Claude clearly distinguish examples from instructions and new input?

Visual framework

TASK → 3–5 GOOD EXAMPLES → NEW INPUT → CLAUDE GENERALIZES → CONSISTENT OUTPUT

Sticky-note reminder: *Five near-identical examples are not truly diverse.*

Try it in practice

You are building a prompt that classifies project updates into Decision, Risk, or Action.

Create three demonstrations:

  1. One obvious/normal example.
  2. One ambiguous example where two categories seem plausible.
  3. One edge case that a simplistic prompt might classify incorrectly.

Then ask: *Do these examples teach the decision boundary, or merely repeat the labels?*

Implementation checklist

  • I understand why demonstrations can be stronger than description alone.
  • My examples closely mirror the real use case.
  • My examples contain meaningful variation.
  • I clearly separate examples from instructions.
  • For important tasks, I can start with 3–5 carefully chosen examples.
  • I check whether my examples accidentally teach an unwanted pattern.

Next session

Structure prompts with XML tags — how to separate instructions, context, examples, and variable inputs so Claude can parse complex prompts more reliably.