Module 03 · Few-Shot and Example-Driven Prompting

Formatting Examples So the Model Copies Structure, Not Content

20 minfocused lesson6practical steps4grounded questions3source links

Open lesson + course map

On this lesson

Course outline

Module 1 · Structural Prompt Frameworks

The CO-STAR Framework: A Structured Prompt Checklist The RTF Framework for Fast, Everyday Prompts Choosing the Right Framework for the Right Task

Module 2 · Reasoning Patterns

Task Decomposition and Verifiable Rationale Self-Critique Loops: Making the Model Check Its Own Work Breaking Multi-Step Tasks Into a Prompt Chain

Module 3 · Few-Shot and Example-Driven Prompting

Zero-Shot vs. Few-Shot: When Examples Actually Help Choosing High-Signal Examples for Consistent Output Formatting Examples So the Model Copies Structure, Not Content

Module 4 · Reusable Instruction Systems

Designing a Personal Prompt Library by Use Case Parameterizing Prompts With Variables for Reuse Version-Controlling Your Best Prompts Like Code

Module 5 · Production-Grade Prompting

Guardrails: Preventing Off-Topic and Unsafe Outputs Testing Prompts Against Edge Cases Before You Ship Capstone: Refactor a Legacy Prompt Into a Production System

Few-shot examples teach both a response pattern and the words inside it. Poor formatting blurs those layers, so a model may reuse a sample name or claim when it should copy only the arrangement.

In this lesson, you will build a three-example block whose structure stays fixed while its subject matter changes. You will then run a topic-transfer test to see whether the model learned the form instead of memorising the payload.

// concept

Separate the Format Contract From the Payload

Write the invariant—the part every valid answer shares—as an output contract. Field names, order, allowed labels, and limits belong here. Names, dates, offers, and messages belong only in the payload.

For a work-request brief:

Layer	Fixed across every case	Changes with each case
Form	Four labels in the same order	Nothing
Rules	One sentence per field; `OPEN_QUESTION` may be `NONE`	Nothing
Payload	Nothing	Task, audience, constraint, missing detail

Use placeholders to define the form and actual sample values inside examples. {AUDIENCE} declares a slot; examples demonstrate how values fill it.

// prompt — copy me8 lines

OUTPUT CONTRACT
TASK: {one action the requester wants completed}
AUDIENCE: {who will receive or use the result}
CONSTRAINT: {one explicit boundary from the input, or NOT PROVIDED}
OPEN_QUESTION: {the single most important missing detail, or NONE}

Do not copy names, dates, products, or claims from examples. Extract each value only
from <new_input>. Do not add a field and do not rename a label.

The final instruction makes separation testable: a sample-only name in the answer is a concrete failure.

// concept

Use Delimiters and Labels That Cannot Be Confused

Delimiters mark where instructions, examples, and new payload begin and end. XML-style tags visibly pair boundaries; Markdown fences also work. Choose one convention and stay consistent.

The examples keep identical tags and labels while changing subject. All names and situations are fictional samples.

// prompt — copy me56 lines

You convert a work request into exactly four labelled lines.

<output_contract>
TASK: one action the requester wants completed
AUDIENCE: who will receive or use the result
CONSTRAINT: one explicit boundary from the input, or NOT PROVIDED
OPEN_QUESTION: the single most important missing detail, or NONE
</output_contract>

Use only facts inside the current input. Examples demonstrate structure, not reusable
facts. Never carry a proper noun, number, date, or offer from one example into another.

<examples>
  <example id="1">
    <input>
    Sample Shop A needs a WhatsApp reply about a late parcel. Keep it under 60 words.
    The courier's revised delivery date is not provided.
    </input>
    <output>
    TASK: Draft a WhatsApp reply about a delayed parcel
    AUDIENCE: The buyer waiting for the parcel
    CONSTRAINT: Keep the reply under 60 words
    OPEN_QUESTION: What revised delivery date has the courier provided?
    </output>
  </example>
  <example id="2">
    <input>
    A Lahore recruiter needs a formal email confirming an online data-analyst
    interview on Tuesday at 3:00 p.m. PKT.
    </input>
    <output>
    TASK: Draft an online interview-confirmation email
    AUDIENCE: The shortlisted data-analyst candidate
    CONSTRAINT: Use a formal tone and state Tuesday at 3:00 p.m. PKT
    OPEN_QUESTION: NONE
    </output>
  </example>
  <example id="3">
    <input>
    A university society needs an Instagram caption for a sample portfolio-review
    event. Registration closes Friday; the venue is undecided.
    </input>
    <output>
    TASK: Draft an Instagram invitation for the portfolio-review event
    AUDIENCE: University students
    CONSTRAINT: State that registration closes Friday
    OPEN_QUESTION: What venue should the caption name?
    </output>
  </example>
</examples>

<new_input>
{{PASTE ONE NEW REQUEST HERE}}
</new_input>

Return only the four labelled lines in <output_contract> order.

The examples share syntax, not vocabulary. They vary channel, audience, constraint, and missing-information state. NONE also shows that a question is not always required.

// concept

Run a Topic-Transfer Test

A familiar-topic pass is weak evidence. Test an absent domain without changing the output contract, then trace every value to the new input.

// prompt — copy me12 lines

TOPIC-TRANSFER TEST

<new_input>
A sample Islamabad clinic needs a reminder for patients whose appointments are
tomorrow morning. The message must not include diagnosis or treatment information.
The clinic has not supplied an arrival time.
</new_input>

Apply the existing <output_contract>. Use only this <new_input> as the factual source.
After the four labelled lines, add `TRANSFER_CHECK: PASS` only if no proper noun,
date, product, event, or offer from an example appears in the answer. Otherwise add
`TRANSFER_CHECK: FAIL — copied: [exact text]`.

// prompt — copy me5 lines

TASK: Draft an appointment reminder for tomorrow morning
AUDIENCE: Patients with appointments tomorrow morning
CONSTRAINT: Do not include diagnosis or treatment information
OPEN_QUESTION: What time should patients arrive?
TRANSFER_CHECK: PASS

This checks form transfer, not outside-world truth. A human must still confirm details before sending.

// worked_example

Worked Example

This bad prompt mixes instructions with an example, changes labels, and lets one fictional brand dominate:

// prompt — copy me4 lines

Make a brief like this. Blue Kite sells lunch boxes. Write:
Brand Blue Kite, Task make a product post, Customer parents, Tone friendly.
Here is the new request: Moon Cart needs an email for office managers about reusable
water bottles. Keep it factual. Make the same output.

A plausible bad draft is: Brand: Blue Kite | Task: product post | Customer: parents | Tone: friendly. It copied the demonstration: Blue Kite, product post, and parents appear nowhere in the target.

The correction defines fields first, fences payloads, varies content, and bans carry-over:

// prompt — copy me31 lines

Return exactly these labels:
ORGANISATION: name stated in <new_input>
DELIVERABLE: requested asset
AUDIENCE: stated recipient, or NOT PROVIDED
BOUNDARY: explicit content or tone rule, or NOT PROVIDED

<example>
<input>Sample Studio needs a formal workshop reminder for registered designers.</input>
<output>
ORGANISATION: Sample Studio
DELIVERABLE: Workshop reminder
AUDIENCE: Registered designers
BOUNDARY: Formal tone
</output>
</example>

<example>
<input>Demo Bakery needs a two-line menu update. Do not mention prices.</input>
<output>
ORGANISATION: Demo Bakery
DELIVERABLE: Two-line menu update
AUDIENCE: NOT PROVIDED
BOUNDARY: Do not mention prices
</output>
</example>

<new_input>
Moon Cart needs an email for office managers about reusable water bottles. Keep it factual.
</new_input>

Copy the labels and order from the format. Take every value only from <new_input>.

// prompt — copy me4 lines

ORGANISATION: Moon Cart
DELIVERABLE: Email about reusable water bottles
AUDIENCE: Office managers
BOUNDARY: Keep it factual

The fix separates schema from samples, pairs delimiters, varies subjects, and makes copied content a test failure.

// failure_cases

Failure Cases to Diagnose

6 cases to diagnose

Sample-only noun appears
Search for every company, person, product, and date from the examples. Diversify the samples and reinforce the current-input boundary.
Examples barely vary
Three clothing-shop examples prove little. Change audiences, channels, and missing-data states while preserving labels.
Labels drift between examples
AUDIENCE in one example and CUSTOMER in another teaches two competing forms. Choose one vocabulary and make every example character-for-character consistent.
Tags are unbalanced or reused
A missing </example> blurs boundaries. Pair every tag and reserve each name for one purpose.
Placeholders leak into the final answer
If {AUDIENCE} or {{PASTE...}} appears in output, add a rule that unresolved slots must become NOT PROVIDED, then test an incomplete input.
The familiar-topic test passes but transfer fails
Rebuild the example set with wider surface variation and rerun an unseen-domain input. Do not publish a reusable prompt based on one convenient demo.

// pakistan_angle

Pakistan Angle

WhatsApp is often where Pakistani clients send mixed English, Urdu, and Roman Urdu briefs. Keep the original language inside <new_input> and state the output language separately; otherwise, an English example can pull a Roman-Urdu request into English. Never paste CNIC images, phone numbers, home addresses, bank details, patient details, or unredacted client chats into a third-party AI tool. Replace them with placeholders such as [PHONE_REDACTED] before creating examples.

For learners working through load-shedding or limited mobile data, store the three-example block as a plain .md or notes-app template and edit only <new_input>. This avoids repeatedly uploading screenshots and makes offline review possible. When a Pakistani date or meeting time matters, write the month in words and include PKT; examples using US date order or an unstated time zone can teach the wrong surface pattern.

// hands_on

Hands-On Exercise

6 steps

Build the lesson artifact: one few-shot block with three structure-consistent, content-varied examples.

Pick a recurring transformation task and define three to five output labels.
Write the output contract with placeholders before writing any sample content.
Add three delimited examples that vary topic, audience, and boundary; include one missing-information case.
Scan the prompt: every fact must sit inside an <input> block, while every instruction must sit outside it.
Run one normal input, then a topic-transfer input from a domain absent from the examples.
Compare both answers with their inputs and record any sample-only phrase that leaked.

// completion_rubric

Completion Rubric

5 checks — tick as you verify

0/5

// sources

Sources

3 official sources — check every claim yourself

// check_yourself

Check yourself

4 questions · answers and options are taken word-for-word from this course

0/4

1 / 4 · diagnose
Your work shows this failure mode: “Examples barely vary.” The lesson describes it like this: “Three clothing-shop examples prove little.” What does the lesson tell you to do about it?