Course: Real World Prompting

Mirrors: Anthropic — Real World Prompting · https://anthropic.skilljar.com/real-world-prompting Audience: Practitioners shipping prompts into real products and workflows. · Time: ~75 min + project Prereqs: prompt-engineering-interactive-tutorial. · Backing notes: prompt-engineering-basics, system-prompts, few-shot-prompting Project: p02-prompt-lab

The interactive tutorial teaches the techniques. This course teaches the process — how prompts get developed, debugged, and shipped against real inputs, and a reusable ~10-part prompt structure you'll reach for every time. By the end you can take a messy real-world task and turn it into a robust, maintainable prompt.

Learning objectives

After this course you can:

• Run the production prompt-development lifecycle: define the task, draft, test on real inputs, debug, iterate, ship, monitor.
• Build prompts from a reusable 10-part structure instead of from scratch.
• Diagnose why a prompt fails and apply the right fix instead of randomly rewording.
• Apply the structure to real industry use cases: support, extraction, content.

---

Module 1 — The prompt-development lifecycle

🎞 Frame 1 · Prompting is engineering, not wording · ⏱ ~3 min

🎬 Scene — A "lucky" one-off prompt fails on the 4th real input; a developer switches from guessing to a repeatable loop.

🧠 Concept — Real prompts aren't found by inspiration; they're developed through a lifecycle: define the task → draft → test on representative inputs → debug → iterate → ship → monitor. Treat the prompt like code. (Deeper: prompt-engineering-basics.)

🖼 On screen

Define task  → write down inputs, outputs, success criteria, edge cases
Draft        → assemble from the 10-part structure (Module 2)
Test         → run on 10–20 REAL, varied inputs
Debug        → identify the failure mode, apply the matching fix
Iterate      → change ONE thing at a time, re-test
Ship         → pin the prompt + model; version it
Monitor      → watch failures in production, feed them back as test cases

✅ Checkpoint — Why test on real inputs rather than the one example you had in mind? (The one in your head is the easy case; real inputs expose edges.)

🎞 Frame 2 · Define the task before you write a word · ⏱ ~3 min

🎬 Scene — Before any prompt, a one-page spec: what goes in, what must come out, what "good" means.

🧠 Concept — Most prompt failures are spec failures. Pin down inputs, the exact output shape, success criteria, and known edge cases before drafting.

🖼 On screen

Inputs:    a customer email (free text, any language, may contain order #)
Output:    {intent, sentiment, needs_human: bool, draft_reply}
Success:   intent correct ≥95%; never invent an order #; reply ≤120 words
Edges:     angry customer · multiple issues · non-English · spam

✅ Checkpoint — Name the four things a task definition must capture. (Inputs, output shape, success criteria, edge cases.)

---

Module 2 — The reusable 10-part prompt structure

🎞 Frame 3 · The 10-part skeleton · ⏱ ~4 min

🎬 Scene — A long system prompt is shown as ten labelled sections stacked in order.

🧠 Concept — Anthropic's real-world structure is a checklist of up to ten parts in a deliberate order. You won't always use all ten, but reaching for them produces robust prompts fast. (Deeper: system-prompts.)

🖼 On screen

1.  Task context          — who Claude is, what the job is
2.  Tone context          — how it should sound
3.  Background data        — reference docs / knowledge (often cached, XML-tagged)
4.  Detailed rules        — the dos and don'ts; principles > conditionals
5.  Examples              — few-shot, in XML tags
6.  Conversation history   — prior turns, if any
7.  The immediate request  — the actual thing to do now
8.  Thinking step          — "think step by step in <thinking> tags"
9.  Output formatting      — the exact shape of the answer
10. Prefill                — opening of the assistant turn to lock format

⚠️ Gotcha — Order matters: stable, cacheable material (1–5) goes up top; the volatile request (7) and prefill (10) go at the bottom.

✅ Checkpoint — Which parts are stable enough to cache, and which change every request? (1–5 stable/cacheable; 6–7 and 10 vary per request.)

🎞 Frame 4 · Parts 1–5: the stable foundation · ⏱ ~4 min

🎬 Scene — Task context, tone, background data, rules, and examples fill the top of the prompt.

🧠 Concept — The first five parts set up who Claude is and what it knows — they rarely change between requests, so they're your cache prefix. Favor principles over conditionals in the rules (deeper: system-prompts), and examples over description for format (deeper: few-shot-prompting).

🖼 On screen

<!-- 1 Task context -->  You are a support agent for ACME Cloud.
<!-- 2 Tone -->          Warm, concise, never condescending.
<!-- 3 Background -->     <kb>{cached_product_docs}</kb>
<!-- 4 Rules -->         - Never promise refunds; route refunds to a human.
                          - Only state facts found in <kb>.
<!-- 5 Examples -->       <examples><example>...</example></examples>

⚠️ Gotcha — Stacking many conditionals at one priority level causes dilution — Claude starts missing rules. Prefer universal principles; put must-never rules under a # CRITICAL header.

✅ Checkpoint — Why prefer "Only state facts found in <kb>" (principle) over a pile of "if X then Y" rules? (Principles hold under pressure; conditionals dilute and get missed.)

🎞 Frame 5 · Parts 6–10: the live request · ⏱ ~4 min

🎬 Scene — History, the immediate request, a thinking step, the output format, and a prefill close out the prompt.

🧠 Concept — The bottom half is what changes each call. End with a thinking step, a precise output format, and a prefill to lock that format from the first token. (Deeper: structured-output.)

🖼 On screen

<!-- 6 History -->        <history>{prior_turns}</history>
<!-- 7 Request -->        <customer_message>{message}</customer_message>
<!-- 8 Thinking -->       Think through intent and the right action in <thinking>.
<!-- 9 Output format -->   Then reply as JSON: {"intent","needs_human","draft_reply"}.
<!-- 10 Prefill (assistant turn) -->   <thinking>

✅ Checkpoint — What does putting the prefill last and the request just above it buy you? (Locked output format and a stable cacheable prefix above the volatile request.)

---

Module 3 — Debugging, iterating, and real use cases

🎞 Frame 6 · Diagnose the failure mode · ⏱ ~4 min

🎬 Scene — A failing output is matched to a row in a failure-mode table; the matching fix is applied — no random rewording.

🧠 Concept — Don't reword randomly. Name the failure mode, then apply its known fix. (Deeper: prompt-engineering-basics.)

🖼 On screen

Symptom	Likely cause	Fix
Chatty / wandering	No format constraint	Add output format + prefill
Wrong format sometimes	Format described in prose	Use a schema or strict examples
Hallucinated facts	Asked to recall, not retrieve	Ground in <context>; "only answer from it"; give an "I don't know" out
Misses edge cases	No examples	Add 2–3 few-shot covering the edges
Ignores a rule	Buried (dilution)	Move rule to top, repeat at end, # CRITICAL

✅ Checkpoint — A prompt invents order numbers. Which row, which fix? (Hallucination → ground in context, forbid invention, allow "not found".)

🎞 Frame 7 · Iterate: change one thing at a time · ⏱ ~3 min

🎬 Scene — A developer changes only the examples, re-runs the same 15 inputs, and compares — then changes only the rules.

🧠 Concept — Iterating is controlled experiments. Change one variable, re-run the same test inputs, compare. Changing three things at once means you learn nothing.

🖼 On screen

Hold inputs fixed (the 10–20 real cases).
Change ONE part of the prompt.
Re-run all cases. Did pass-rate go up, down, or sideways?
Keep the win, revert the loss. Repeat.

🔗 This controlled loop is exactly what an eval harness automates — see prompt-evaluations.

✅ Checkpoint — Why hold the test inputs fixed while iterating? (So any change in results is attributable to the one prompt change, not to different inputs.)

🎞 Frame 8 · Use case: customer support · ⏱ ~3 min

🎬 Scene — The 10-part structure instantiated for a support reply agent grounded in product docs.

🧠 Concept — Support needs grounding + boundaries: answer only from the knowledge base, escalate on refunds/legal, match brand tone. Principles in the rules, KB cached as background data.

🖼 On screen

Task: resolve or route a support ticket.
Background: cached product KB in <kb>.
Rules (principles): only state KB facts; route refunds/legal to a human.
Output: {intent, needs_human, draft_reply}.  Thinking step before the reply.

✅ Checkpoint — Which two of the 10 parts most reduce wrong support answers? (Background data grounding + rules/principles forbidding invention.)

🎞 Frame 9 · Use case: extraction · ⏱ ~3 min

🎬 Scene — Messy invoices flow in; clean, schema-conformant JSON with source pointers flows out.

🧠 Concept — Extraction wants a forced output schema and provenance. Pair the 10-part structure with a forced tool, and ask Claude to cite where each value came from for auditability. (Deeper: structured-output.)

🖼 On screen

{"vendor": "ACME", "vendor_source": "page 1, line 2",
 "total": 482.10, "total_source": "page 2, 'Total Due'"}

✅ Checkpoint — What does adding *_source fields give you? (Auditable, spot-checkable extractions.)

🎞 Frame 10 · Use case: content & wrap-up · ⏱ ~3 min

🎬 Scene — A brand-voiced blog draft is generated from a cached style guide and three example posts, then the lifecycle slide recaps.

🧠 Concept — Content generation leans on tone context + examples: cache the style guide, show 3 on-brand examples, give a tight brief. Then recap: define → draft from the 10 parts → test on real inputs → debug by failure mode → iterate one change at a time → ship and monitor.

🖼 On screen

Content recipe:
  Tone context  = brand voice rules
  Background    = cached style guide
  Examples      = 3 on-brand posts (XML-tagged)
  Request       = the brief + constraints (length, CTA, audience)

✅ Checkpoint — Without looking, list the lifecycle stages. (Define → draft → test → debug → iterate → ship → monitor.)

---

🛠 Project

Complete p02-prompt-lab — The Prompt Lab in "real-world" mode: pick one real task (support, extraction, or content), write its task definition, build the prompt from the 10-part structure, gather 10–20 real inputs, run them, and iterate one change at a time through at least three rounds — logging the failure mode you fixed each round.

🧪 Self-check quiz

1. List the prompt-development lifecycle stages.
2. What four things must a task definition capture before you draft?
3. Roughly what are the ten parts of the reusable prompt structure (name any seven)?
4. Which parts are stable enough to cache, and which vary per request?
5. Why prefer principles over conditionals in the rules section?
6. A prompt occasionally returns the wrong format. What's the fix?
7. Why change only one thing at a time while iterating?
8. What makes an extraction auditable?

<details><summary>Answers</summary>

1. Define → draft → test → debug → iterate → ship → monitor. 2. Inputs, output shape, success criteria, edge cases. 3. Task context, tone, background data, rules, examples, conversation history, the request, thinking step, output formatting, prefill. 4. Parts 1–5 are stable/cacheable; history, the request, and prefill vary per request. 5. Principles hold under pressure; stacking conditionals causes dilution and missed rules. 6. Replace prose format with a schema or strict examples (and prefill). 7. So results are attributable to that single change, not confounded. 8. Provenance — *_source pointers next to each extracted value.

</details>

🎓 Certificate criteria

You've "passed" Real World Prompting when you can:

• Run a real task through the full prompt-development lifecycle.
• Build a prompt from the 10-part structure and explain why each part is ordered where it is.
• Diagnose a failure by naming its mode and applying the matching fix.
• Iterate one change at a time against a fixed set of real inputs.
• Complete p02-prompt-lab in real-world mode and journal the three failure modes you fixed.

Tick this course off in progress and record the date you earned Anthropic's official certificate.

🔗 Sources & deeper notes

• Official course: https://anthropic.skilljar.com/real-world-prompting
• Vault notes: prompt-engineering-basics, system-prompts, few-shot-prompting, structured-output
• Next course: prompt-evaluations — measure what you built