Module 1 — Prompts as Reusable Artifacts

Source: Anthropic’s Prompting Best Practices + Prompt Engineering Essentials + Troubleshooting Claude + Prompt Caching & Agency Economics

Time: Read 12 min | Watch 20 min | Practice 45 min — total ~75 min

Read First

The intro course taught you RCTF — Role, Context, Task, Format. That’s the chassis. This module bolts on the engine.

Before you start, skim the two anchor references — you don’t need to memorize them, but you’ll see them cited throughout the module:

• Anthropic’s Prompting Best Practices — the official reference. Read the sections on XML tags, multi-shot examples, and chain-of-thought (~10 min).
• Prompt Engineering Essentials — the consolidated WEO patterns sheet (~5 min).

If you want a 20-minute video walkthrough, the Anthropic Academy Prompt Engineering Interactive Tutorial covers most of these techniques with runnable examples — link from the prompting-best-practices article.

Why It Matters at WEO

Intro Module 2 made the case for writing better prompts. This module makes a different case: the prompts that earn their keep are the ones you stop writing.

A one-shot RCTF prompt costs 90 seconds and produces a usable headline. Worth it. But by month three of using Claude this way, the math turns ugly. You are typing the same Smile Springs Context block into a fresh chat for the eighth time this week. The voice rules drift each time you re-type them. New hires invent their own version. Your output reads like five different copywriters touched it because, functionally, five different versions of you did.

A reusable artifact fixes all four problems at once. The prompt becomes the deliverable. You build it once, version it, share it, and run it as a fill-in-the-blank job from then on. Three things change:

• Voice consistency goes from “depends on the day” to deterministic. Every Smile Springs draft starts from the same Role, the same banned-phrase list, the same examples of on-brand voice. The output variance collapses.
• Onboarding gets cheaper. A new strategist who joins WEO opens the prompt library, runs four template prompts on their first client, and produces work indistinguishable from someone who’s been here a year. The prompt holds the institutional knowledge — they don’t have to.
• Prompt caching turns into real money. The reusable scaffold (Role + Context + examples + rules — usually 1,500–3,000 tokens) caches at 90% off every time you re-run it. On a busy week with 200 client briefs, that’s the difference between a $40APIbillanda$4 one. See the agency economics article for the worked Smile Springs numbers.

The shift in mental model: you used to write prompts for a single output. Now you build prompts as products that produce many outputs. The investment is bigger up front. The payoff compounds for as long as you use it.

The Eight Techniques

These eight build on top of RCTF. Pick one or two for any given prompt — you don’t need all eight every time. The Worked Example below stacks five of them on the same artifact so you can see how they compose.

1. Constraint stacking — telling Claude what NOT to do

Constraints are the fastest quality lift you can add to any prompt. They’re cheaper than instructions because telling Claude what to avoid is more reliable than telling it what to produce.

The pattern: list the failure modes you’ve already seen, and forbid them by name.

For Smile Springs, Mel’s banned-phrase list is well-documented at this point. Stack it directly into the prompt:

Constraints:
- Never use: streamline, leverage, world-class, game-changer,
  state-of-the-art, revolutionize, dazzle.
- Never write "in today's fast-paced world" or any sentence that
  starts with "In today's [X], more than ever..."
- No clinical jargon (gingivitis, prophylaxis, periodontitis) unless
  the patient asked about it directly.
- No emoji. No exclamation points except inside quoted patient testimonials.
- No rhetorical questions in the opening sentence.

Constraint stacking compounds. Every banned word or pattern is a failure mode that no longer wastes your editing time. The first version of any reusable artifact has 5 constraints. The third version has 15, and most were earned the hard way — Claude produced the failure, you noticed, you added the rule.

2. XML structuring — labeling the parts of your prompt

Claude was trained on a lot of XML-tagged data. When you wrap sections of your prompt in tags like <role>, <context>, <rules>, and <examples>, Claude treats them as semantically distinct — and it can reliably reference them in its reasoning.

The pattern looks like this:

<role>
Senior dental marketing copywriter, 10 years of family-practice experience.
</role>

<context>
Practice: Smile Springs Family Dental
Location: Columbus, Ohio
Audience: families with kids, adults 35-55
Voice: warm, plainspoken, trustworthy — not clinical
Differentiator: Saturday appointments, no-wait booking
</context>

<task>
Write 5 homepage headline variations.
</task>

<rules>
- Max 8 words each
- Numbered list
- No banned phrases (see banned-phrases tag below)
</rules>

<banned_phrases>
streamline, leverage, world-class, game-changer, state-of-the-art,
revolutionize, dazzle, "in today's fast-paced world"
</banned_phrases>

<output_format>
1. [headline]
2. [headline]
...
</output_format>

Why this works better than the same content written as plain prose: Claude can isolate each section when reasoning. You can also write higher-order instructions like “check your output against the rules in <rules> and <banned_phrases>” and Claude will go find those tags and use them. Plain-prose prompts blur sections together; XML keeps them separate.

XML isn’t decorative. The first time you write “review your output against <banned_phrases> and flag any matches”, you’ll see the difference. Without the tag, Claude searches its own context loosely; with it, Claude finds the exact list and runs against it.

3. Multi-shot examples — teaching voice with samples

Voice is the single hardest thing to teach Claude with instructions. “Warm, plainspoken, not clinical” sounds clear, but it’s still abstract — Claude has to invent what “warm” means for a dental practice in Columbus.

Examples teach faster. Paste 2–3 actual on-brand outputs into the prompt as <example> blocks, and Claude transfers the voice signature with much higher fidelity than instructions alone.

For Smile Springs, you’d take three real homepage headlines that your team agreed are on-brand and paste them in:

<examples>
Example 1: "Saturday cleanings that don't wreck your weekend."
Example 2: "Your kids' first cleaning, made un-scary."
Example 3: "We answer the phone. We see you on time. That's it."
</examples>

Then ask Claude to write more in the same voice. The lift over instruction-only prompts is dramatic — examples capture sentence rhythm, vocabulary range, and the implicit “what we don’t say” that’s nearly impossible to articulate in rules.

Two notes on examples:

• Use 2–3, not 1 and not 10. One example reads as the template (Claude copies its structure too literally). Ten examples is enough that Claude starts averaging across them and produces blander output. Three is the sweet spot.
• Examples beat instructions for voice; instructions beat examples for rules. If you want Claude to never use a banned phrase, write it in <rules>, not in <examples>. Examples teach what you do want; rules teach what you don’t.

4. Chain-of-thought — make Claude reason before answering

Some tasks need Claude to think before producing output. Asking for a homepage headline doesn’t — Claude can produce one in one shot. Asking for “the three headlines most likely to convert parents booking their first family visit” needs reasoning.

The pattern: tell Claude to think first, then answer.

Before writing the headlines, think through:
1. What specific objection or hesitation does a Columbus parent have
   about booking a new dental practice?
2. Which of Smile Springs' differentiators (Saturday hours,
   no-wait booking, kids-friendly) maps best to that objection?
3. What word choices feel warm without feeling salesy?

Wrap your reasoning in <thinking></thinking> tags.

After your reasoning, write 5 headline variations.

Claude will produce a <thinking> block, work through the questions, and then write the headlines. The headlines will be sharper than what one-shot prompting produces — because Claude has primed itself with the right considerations.

When to use chain-of-thought: any task where the quality of the output depends on which mental model Claude uses to approach it. Strategy work, audience-specific copy, anything with multiple competing tradeoffs. Don’t use it for simple structured output (a list, a table) — it adds latency without lifting quality.

5. Structured output formats — when to enforce, when to leave loose

Claude can output JSON, markdown tables, fenced code blocks, or any structured shape you describe. The skill is knowing when to enforce the structure and when to leave it loose.

Enforce structure when:

• The output feeds directly into another tool (a spreadsheet import, a CMS, a downstream Claude call).
• The user reading the output is scanning for specific fields (a comparison matrix, a brief specification).
• You need to verify completeness (every row must have all 5 columns; if a column is empty, the artifact is wrong).

For Smile Springs FAQ generation, you’d enforce a JSON output:

{
  "faq": [
    {
      "question": "Do you take new patients?",
      "answer": "Yes — typically same-week. Saturday slots fill fastest.",
      "voice_check": "warm, factual, no jargon",
      "banned_phrase_check": "clean"
    }
  ]
}

Leave structure loose when:

• The output is creative work where over-constraint flattens voice.
• You don’t yet know the right shape — early iterations of a prompt benefit from Claude experimenting with structure.
• The output is for a human who can scan prose comfortably.

The mistake: forcing rigid structure on creative output. Asking for a strict JSON schema for headlines flattens voice — Claude treats every field as a slot to fill, not a piece of writing. Headlines belong in a numbered list, not a nested JSON.

6. Validation-with-retry — Claude checks its own output

This is the technique that turns a good prompt into a production artifact. After Claude produces output, you ask it to check the output against the rules — and rewrite anything that fails.

The pattern, written into the prompt itself:

<workflow>
Step 1: Produce 5 headlines following all rules in <rules>.
Step 2: Review each headline against <banned_phrases>. For any
        match, rewrite the headline.
Step 3: Review each headline against <examples> for voice
        consistency. If a headline reads off-voice, rewrite it.
Step 4: Output only the final clean version. Do not show
        intermediate drafts.
</workflow>

Claude will internally produce a draft, run it against the rules, and ship the corrected version. The output quality jumps because Claude is doing one round of editing before you ever see the result.

Two design notes:

• Be explicit about what “passes.” “Review for voice” is too vague. “Check that no headline starts with ‘In today’s’ and that no headline uses ‘streamline,’ ‘leverage,’ or ‘world-class’” is checkable.
• Decide whether you want to see the validation pass. “Output only the final clean version” is faster to use. “Show your validation pass and the corrections you made” is slower but teaches you how Claude is reasoning — useful when iterating on the artifact itself.

7. The interview pattern — Claude asks YOU questions before producing

For high-ambiguity briefs, the most reliable move is to flip the conversation: tell Claude to ask you clarifying questions before it produces any output.

Before producing any output, ask me 3–5 clarifying questions about
this brief. Cover gaps in: target audience specifics, brand voice
constraints I haven't mentioned, the desired action the reader
should take, any banned topics or phrases.

After I answer, produce the deliverable.

This pattern is gold for the situation where you’ve sketched a brief in 90 seconds and you know it’s underspecified — but you don’t yet know which parts are underspecified. Claude finds the gaps and asks. You answer. The brief that goes into production is much sharper than what you’d have written if you’d tried to anticipate every detail upfront.

When to use interview: any brief that’s longer than 3 sentences and shorter than fully-specified. Skip it for tightly-scoped tasks (“write 5 homepage headlines for Smile Springs, no banned phrases, max 8 words each”). Use it for fuzzy ones (“we need a campaign for Smile Springs’ summer kids’ check-up promotion”).

A small variant: ask Claude to ask one question per turn rather than 3–5 at once. That’s slower but produces sharper questions because each one builds on the last answer.

8. Self-correction loops — Claude reviews its own draft against constraints

Self-correction extends validation-with-retry: instead of just checking a final output against rules, Claude produces a draft, critiques the draft against your standards, lists specific issues, and proposes fixes — then you decide whether to accept the fixes.

The prompt pattern:

<workflow>
Step 1: Write a draft of the new-patient FAQ (10 questions, full answers).
Step 2: Read your draft as if you were Mel — Smile Springs' marketing
        director. Mel's pet peeves: corporate jargon, sentences
        starting with "Are you tired of...", any word from the banned list,
        clinical jargon for non-clinical questions, hedging language
        like "may help" or "could potentially."
Step 3: Produce a critique block listing every issue you found.
        Format: "Q3 answer uses 'leverage' — rewrite to 'use'."
Step 4: Produce the corrected final version with all fixes applied.

Output all four steps. I want to see the draft, the critique, and
the corrections — not just the final.
</workflow>

Self-correction surfaces something rules-only validation doesn’t: judgment calls. The validation-with-retry pattern catches banned phrases. The self-correction loop catches “this sentence is technically allowed but reads off-voice.” Claude makes the judgment call, shows its reasoning, and you can disagree.

Use self-correction when:

• The output bar is “production-ready, ship it tomorrow.”
• You’re iterating on the prompt artifact itself and want to see what Claude is catching that the rules don’t enumerate.
• The work is high-stakes (client-facing, paid media, anything that can’t be rolled back easily).

Worked Example — Smile Springs New-Patient FAQ Generator

This is the centerpiece of the module. The same task — generate 10 new-patient FAQ entries for Smile Springs Family Dental — written three ways, showing how the techniques compose.

Run all three in your own Claude account if you have time. The quality jump from v1 → v3 is the entire point of this module.

v1 — Plain RCTF (your intro Module 2 baseline)

Role: You are a senior dental marketing copywriter specializing in
family practices.

Context: Smile Springs Family Dental is in Columbus, Ohio. The
audience is families with kids and adults 35-55. The brand voice
is warm, plainspoken, trustworthy — not clinical. Key
differentiator: Saturday appointments and no-wait booking.

Task: Write 10 FAQ entries for the new-patient page. Cover topics
new patients commonly ask about: insurance, scheduling, kids,
emergencies.

Format: Numbered list. Each entry has a Q: line and an A: line.
Keep answers under 60 words.

What you get: The output is acceptable — answers are under 60 words, hits the topics. But run it three times in fresh chats and you get three meaningfully different voices. One run uses “leverage our Saturday hours” and “state-of-the-art.” Another uses unprompted exclamation points. A third opens half the answers with rhetorical questions (“Worried about your child’s first visit?”). Voice drift across runs is the v1 failure mode.

v2 — RCTF + XML + multi-shot + banned-phrase list

<role>
Senior dental marketing copywriter, 10 years of family-practice
experience. Direct-response background. Allergic to corporate jargon.
</role>

<context>
Practice: Smile Springs Family Dental
Location: Columbus, Ohio
Audience: families with kids, adults 35-55
Voice: warm, plainspoken, trustworthy — not clinical
Differentiator: Saturday appointments, no-wait booking
</context>

<task>
Write 10 FAQ entries for the new-patient page. Cover: insurance,
scheduling, first visits for kids, emergencies, what to expect on
first appointment.
</task>

<rules>
- Each entry: a Q: line and an A: line
- Answers under 60 words
- Numbered list
- No emoji, no exclamation points (except inside quoted testimonial)
- No rhetorical questions as openers
- No clinical jargon unless the question itself is clinical
</rules>

<banned_phrases>
streamline, leverage, world-class, game-changer, state-of-the-art,
revolutionize, dazzle, "in today's fast-paced world",
"are you tired of", "more than ever"
</banned_phrases>

<examples>
Example A:
Q: Do you take walk-ins?
A: Most days, yes — call ahead and we'll usually fit you in within
the hour. Saturdays are our busiest day, so booking helps.

Example B:
Q: What if my kid has never been to the dentist?
A: We start with the chair — we let them sit in it, push the
buttons, and meet the team. The cleaning happens once they're
comfortable, not before.

Example C:
Q: Do you take my insurance?
A: We're in-network with most major Ohio plans. Send us your card
when you book and we'll confirm before your appointment, no
surprises.
</examples>

<output_format>
1.
Q: [question]
A: [answer]

2.
Q: [question]
A: [answer]
... (etc.)
</output_format>

What you get: A serious step up. The voice is consistent across runs because the examples lock it in. The banned phrases never appear. The structure is exactly what you asked for. You’d ship this with maybe one or two small edits.

But there’s still a gap: nothing checks the output. If Claude has a bad day and slips a “state-of-the-art” through, you only catch it on read-through. For high-volume use, that’s a leak.

v3 — Add validation-with-retry + self-correction loop

<role>
Senior dental marketing copywriter, 10 years of family-practice
experience. Direct-response background. Allergic to corporate jargon.
</role>

<context>
Practice: Smile Springs Family Dental
Location: Columbus, Ohio
Audience: families with kids, adults 35-55
Voice: warm, plainspoken, trustworthy — not clinical
Differentiator: Saturday appointments, no-wait booking
</context>

<task>
Generate 10 FAQ entries for the new-patient page. Cover: insurance,
scheduling, first visits for kids, emergencies, what to expect.
</task>

<rules>
- Each entry: a Q: line and an A: line
- Answers under 60 words
- Numbered list
- No emoji, no exclamation points (except inside quoted testimonial)
- No rhetorical questions as openers
- No clinical jargon unless the question itself is clinical
- No hedging language ("may help", "could potentially")
- Active voice
</rules>

<banned_phrases>
streamline, leverage, world-class, game-changer, state-of-the-art,
revolutionize, dazzle, "in today's fast-paced world",
"are you tired of", "more than ever"
</banned_phrases>

<examples>
Example A:
Q: Do you take walk-ins?
A: Most days, yes — call ahead and we'll usually fit you in within
the hour. Saturdays are our busiest day, so booking helps.

Example B:
Q: What if my kid has never been to the dentist?
A: We start with the chair — we let them sit in it, push the
buttons, and meet the team. The cleaning happens once they're
comfortable, not before.

Example C:
Q: Do you take my insurance?
A: We're in-network with most major Ohio plans. Send us your card
when you book and we'll confirm before your appointment, no
surprises.
</examples>

<workflow>
Step 1 — Draft.
Write a complete first draft of all 10 FAQ entries. Don't optimize
yet — just produce a draft that hits the topics.

Step 2 — Validate against rules and banned phrases.
Read your draft. For each entry, check:
- Answer is under 60 words? (count silently if unsure)
- No words from <banned_phrases>?
- No rhetorical-question opener?
- No emoji or exclamation points?
- No hedging language?
List every violation in a <validation> block, formatted:
"Q[#]: [issue] — [proposed fix]"

Step 3 — Voice critique (read as Mel).
Read your draft as if you were Mel, Smile Springs' marketing
director. Mel's pet peeves beyond the rules:
- Sentences that sound like a brochure ("our commitment to...")
- Generic opener patterns ("At Smile Springs Family Dental, we...")
- Anything that doesn't sound like a real person talking to
  another real person
List issues in a <voice-critique> block.

Step 4 — Final output.
Apply all fixes. Produce the corrected 10 FAQ entries in the
output format below. After the entries, include a brief
<self-report> noting how many fixes you applied and what
categories they fell into.
</workflow>

<output_format>
After the workflow steps:

## Final FAQ

1.
Q: [question]
A: [answer]

2.
Q: [question]
A: [answer]
... (etc.)

<self-report>
Total fixes applied: [N]
Categories: [list]
</self-report>
</output_format>

What you get: Production-ready output every run. The voice is locked in. The validation catches drift. The self-critique catches the judgment-call issues that rules miss. The <self-report> tells you what Claude caught — useful signal for evolving the artifact.

This v3 prompt is ~80 lines. You’d save it as a Project instruction in claude.ai (so it auto-loads on every Smile Springs chat) or as a slash command in Claude Code. From then on, generating a fresh FAQ for any topic is a one-line ask: “Generate the 10 entries — focus this batch on emergency-visit topics.” The artifact handles the rest.

This is what “promoting prompts to artifacts” means concretely: 90 seconds of typing replaced by a sub-second invocation against a 30-line scaffold that produces production-quality work.

When To Use Which Technique

You won’t stack all eight techniques on every prompt. Reach for them based on what kind of work you’re producing.

Work type	Default stack
One-off creative (a single ad, a single headline batch)	RCTF + Constraints + 2–3 Examples
Recurring deliverable (weekly content, FAQ generation, brief drafting)	Full v3: XML + Examples + Constraints + Validation + Self-correction
High-ambiguity brief (campaign concept, strategy outline)	RCTF + Interview pattern (Claude asks YOU first)
Reasoning-heavy (audit, teardown, “which option is best”)	RCTF + Chain-of-thought + Structured output
Downstream-tool consumption (JSON for an import, a CMS push)	RCTF + Strict structured output + Validation
First time writing a prompt for a new task	Start with v1 RCTF. If it’s a one-off, ship it. If you’ll run this twice in 30 days, evolve to v3.

The decision rule: use the lightest stack that gets the quality bar. Adding XML and validation to a prompt you’ll run once is over-engineering. Adding them to a prompt you’ll run 200 times this year is the difference between consistent output and constant edits.

Reasoning Controls — Extended Thinking and Adaptive Thinking

Two intermediate Claude features control how hard Claude reasons before answering. The default is good for most chat work; the controls matter when your artifact’s quality depends on careful step-by-step thinking.

Extended Thinking — manual reasoning budget

Extended Thinking lets you tell Claude to reason out loud (in a hidden thinking block) before producing the final answer. You set a token budget for the thinking phase.

When to reach for it:

• Reasoning-heavy artifacts — audits, teardowns, multi-criteria comparisons, anything where Claude needs to weigh evidence rather than retrieve it. Pair with chain-of-thought from Technique 4.
• High-stakes one-shots — when getting it wrong on the first try costs you a lot of editing time, and you’d rather Claude take longer up front.
• Validation steps — the validation pass in Technique 6 benefits from extended thinking because checking against rules is a careful step-by-step job.

When to skip it:

• Creative work (headlines, hero copy, ad variants) — extended thinking doesn’t make Claude more creative, just slower and more expensive.
• Routine fill-in-the-blank artifacts where the v3 scaffold already does the work.
• Anything you’re going to iterate on quickly — extended thinking adds latency.

Adaptive Thinking — model decides

Adaptive Thinking is the newer default on Opus 4.7 and Sonnet 4.6: Claude decides per-prompt whether to reason extensively or answer immediately based on perceived task difficulty. It’s on by default in claude.ai and can be toggled off in Claude Code via the model config.

The intermediate move: leave Adaptive Thinking on for general work; force Extended Thinking with an explicit budget when you need predictable depth. A reusable artifact that’s expected to handle hard cases (a teardown, a multi-criteria audit) is the right place for an explicit Extended Thinking budget — you don’t want the model deciding “this looks easy” and skipping the deep reasoning your artifact was designed for.

Effort tier (Pro/Max only)

On Pro and Max plans, you can set the default effort tier (high / xhigh) per session, which raises the floor on how much reasoning Claude allocates by default. xhigh is the right choice when you’re inside a long working session on a hard artifact — your individual prompts get more thinking budget without you naming it each time. See Opus 4.7 Best Practices for the full effort/tier matrix.

Common Failure Modes

For the deep dive on what goes wrong with prompts and how to recover, see Troubleshooting Claude — the article covers refusal, context exhaustion, hallucination, tool-use errors, and the recovery moves for each.

The three failure modes you’ll hit most often when building reusable artifacts:

1. Voice drift between runs. You wrote a v2 with examples and rules, but every fresh run reads slightly different. Diagnosis: the examples don’t cover enough of the voice surface area, or the rules contradict the examples. Fix: add a third example that covers a different tonal register (one warm, one factual, one casual), and audit your rules against the examples — if a rule says “no contractions” but Example A uses “we’ll”, Claude is getting mixed signals.

2. Validation pass rubber-stamps everything. You added a “review your output against the rules” step. Claude says it reviewed. Output still has banned phrases. Diagnosis: the validation step is too loose — Claude treats it as performative. Fix: require Claude to list what it checked, not just say it checked. “Output a <validation> block listing each banned phrase from <banned_phrases> and whether you found it in your draft. If you found any, rewrite that entry.” Forcing the listing makes the check real.

3. Artifact bloats and starts contradicting itself. Three months in, your prompt is 200 lines. New rules conflict with old examples. Output quality drops. Diagnosis: you’ve been adding without auditing. Fix: every 90 days, run a “prompt review” pass — paste the artifact into a fresh chat and ask Claude “read this prompt and flag any contradictions, redundancies, or rules that conflict with the examples.” Apply the fixes. Trim the artifact back to a clean version.

Key Takeaways

• A prompt becomes an artifact the moment it’s worth saving and re-running. The bar: you’d otherwise rewrite it from memory.
• Eight techniques compose on top of RCTF: constraint stacking, XML structuring, multi-shot examples, chain-of-thought, structured output, validation-with-retry, the interview pattern, and self-correction loops.
• Examples teach voice. Rules teach what not to do. Both belong in the artifact, in different sections.
• XML tags aren’t decorative — they let Claude isolate and reference specific parts of the prompt during reasoning and validation.
• Validation-with-retry and self-correction are the techniques that move a prompt from “good” to “production-ready.” They build in a round of editing before you see output.
• Use the interview pattern for high-ambiguity briefs. Use chain-of-thought for reasoning-heavy work. Use strict structured output only when downstream tools need it.
• The economic case for reusable artifacts is real — prompt caching makes the v3 pattern cheaper per run than the v1 pattern, not more expensive. See the agency economics article for the math.
• Audit your artifacts every 90 days. Bloat creeps in; rules drift; examples go stale. Trim them back.

Related

• Course index
• Intro Module 2 — Prompting Fundamentals (RCTF baseline)
• Anthropic’s Prompting Best Practices
• Prompt Engineering Essentials
• Troubleshooting Claude — failure-mode recovery
• Prompt Caching & Agency Economics
• Next: Module 2 — Skills at Depth: Shop, Vet, Build

Try It

Two exercises. The first is mandatory; the second is optional for the Builder track.

1. [Both] Promote one of your existing prompts to a v3 artifact (35 min)

Pick a real prompt you wrote in intro Module 3 — the RCTF version of a recurring task you actually do (FAQ drafting, blog outlines, email subject lines, ad variants, anything you’d run more than twice).

Convert it through the three versions:

• v1: Your existing RCTF prompt. Run it once on a real Smile Springs (or real client) brief. Save the output.
• v2: Add XML structure, 2–3 multi-shot examples pulled from real on-brand work, a banned-phrase list, and a constraint stack. Run on the same brief. Save the output.
• v3: Add a validation-with-retry workflow that checks output against the rules, plus a self-correction step that critiques voice as Mel would. Run on the same brief. Save the output.

Compare the three outputs side by side. Note specifically:

• Which version’s output would you ship with the fewest edits?
• Which version’s output reads most consistently with the brand?
• What did the validation step actually catch that you would have caught manually?

Save the v3 prompt to your prompt library. Name it {role}_{task}_v3.md. Use it for that task from now on.

2. [Builder, optional] Save your v3 artifact as a Claude Code slash command (10 min)

If you have Claude Code installed and want to make the artifact invokable from any directory:

• Create ~/.claude/commands/voice-faq-smile-springs.md (or your client’s equivalent).
• Paste the v3 prompt body into the file.
• Save.

From any Claude Code session, run /voice-faq-smile-springs and Claude will load the artifact as the system prompt for that turn. You then provide the brief as a normal message (“Generate 10 entries focused on emergency-visit topics”). Claude runs the full v3 workflow against your brief.

This pattern is how Claude Code users build a personal CLI of high-leverage prompts. Your library becomes a tool palette, not a notes file. Module 6 covers the full Builder Track on Claude Code if you want to go further.

Done? Move on to Module 2 — Skills at Depth — where the artifacts you’ve just learned to build get packaged into shareable, installable skills.