Week 2: Prompt Engineering Fundamentals

Most disappointing Claude output traces back to one of a small number of prompting mistakes, not a model limitation. This week covers the handful of techniques that do most of the work: being genuinely clear and direct instead of vague, giving Claude the context it needs instead of just an instruction, showing it examples of what "good" looks like, and using structure so a long or multi-part prompt doesn't turn into a wall of text Claude has to guess how to parse.

Module 1 of 14 Week 2 of 14 ~2.5 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Turn a vague ask into a clear, direct prompt with explicit success criteria
  • Use a few well-chosen examples to steer format, tone and edge cases
  • Structure a multi-part prompt with XML tags so nothing gets missed

1. Being Clear and Direct

Claude doesn't have access to what's in your head — only to what's in the prompt. A vague instruction leaves it guessing at exactly the things you care about most: scope, format, tone, and what "done" looks like. The fix isn't a magic phrase, it's just... saying the quiet part out loud.

vague vs. direct — same request, very different results
VAGUE:
"Write something about our new pricing page."

DIRECT:
"Write a 150-word announcement for our new pricing page, for existing
customers via email. Tone: friendly, not salesy. Lead with the fact that
existing plans aren't changing. End with a single clear CTA: 'See the new
plans' linking to /pricing. Do not mention specific dollar amounts."

The direct version answers, up front, every question Claude would otherwise have to guess at: length, audience, tone, structure, and an explicit constraint (no dollar amounts) that a vague prompt would never have surfaced until you saw the wrong output and had to correct it. Every one of those specifics you supply is one less thing Claude has to guess — and less guessing means less rework for you.

A useful test

Read your prompt back and ask: "if a new hire with no context read only this, would they produce what I actually want?" If the honest answer is "they'd have to guess at three things," those three things belong in the prompt.

2. Give Claude Context, Not Just Instructions

An instruction says what to do. Context says why, and why matters more than it seems — it lets Claude make good judgment calls on the countless small decisions an instruction alone doesn't cover.

instruction alone vs. instruction + context
INSTRUCTION ALONE:
"Summarize this contract in 3 bullet points."

INSTRUCTION + CONTEXT:
"Summarize this contract in 3 bullet points. This is for a non-lawyer
founder deciding whether to sign — focus on financial obligations,
termination conditions, and anything unusual compared to a standard SaaS
agreement. Skip standard boilerplate clauses entirely."

With just the instruction, Claude has to guess what "important" means for a 3-bullet summary of a legal document — and a reasonable guess might pick the wrong three things for your actual purpose. The context version tells Claude who's reading it and what decision it's for, which changes what counts as important information in a way no amount of rephrasing the instruction alone could fix.

Context includes the audience

"Who is this for, and what will they do with the answer?" is often the single highest-leverage sentence you can add to a prompt — it silently answers dozens of smaller formatting and content decisions at once.

3. Few-Shot Examples

Sometimes the shape of a good answer is much easier to show than to describe. Few-shot prompting means giving Claude one or more examples of input paired with the exact kind of output you want, before asking it to do the real one.

zero-shot vs. few-shot for a classification task
ZERO-SHOT:
"Classify this support ticket's urgency: 'My export button is grayed out
on Tuesdays only, otherwise fine.'"
→ Claude has to guess your urgency scale AND your output format.

FEW-SHOT:
"Classify ticket urgency as LOW, MEDIUM or HIGH.

Ticket: 'Site is completely down, we're losing sales right now.'
Urgency: HIGH

Ticket: 'Small typo in the footer copyright year.'
Urgency: LOW

Ticket: 'My export button is grayed out on Tuesdays only, otherwise fine.'
Urgency:"

Two examples pin down both the exact label vocabulary (LOW/MEDIUM/HIGH, not "urgent"/"not urgent") and the exact output format (just the label, no explanation) — both things that would otherwise require a paragraph of instructions to specify, and even then might not be followed as reliably as two clean examples achieve immediately.

Pick examples that cover edge cases

Two or three examples that only cover the "obvious" cases won't help with the ambiguous ones. Include at least one example near a boundary (a ticket that's borderline MEDIUM/HIGH, say) so Claude sees how you actually want ties broken.

4. XML Tags for Structuring Prompts

Once a prompt has multiple moving parts — instructions, reference material, examples, formatting rules — plain paragraphs make it easy for Claude (and for you, re-reading it later) to lose track of what's an instruction versus what's content to act on. Claude is trained to pay close attention to XML-style tags, so wrapping distinct parts of a prompt in tags like <document> or <instructions> reliably keeps them separate.

an unstructured prompt vs. a tagged one
UNSTRUCTURED (ambiguous — is "keep it under 100 words" about the summary
or about the whole reply, including any caveats Claude adds?):

"Here is an article: [long article text]. Summarize it in one paragraph
for a busy executive, keep it under 100 words, and here's an example of
the tone I want: [example text]."

TAGGED (unambiguous — every part has exactly one clear role):

<document>
[long article text]
</document>

<example_tone>
[example text]
</example_tone>

<instructions>
Summarize the document above in one paragraph, under 100 words, for a
busy executive. Match the tone shown in example_tone.
</instructions>

This pays off most on long or complicated prompts: multi-document comparisons, prompts that mix reference material with instructions, or system prompts that need to cleanly separate "background you should know" from "rules you must follow." There's no fixed tag vocabulary to memorize — pick names that describe their contents (<code>, <requirements>, <examples>) and be consistent within a prompt.

You'll use this constantly from here on

XML-tag structuring shows up again in Week 3 for structured output, and it's exactly how you'll separate "the code you're working on" from "the instructions for this change" once you get to Claude Code in Week 10 — this is a foundational habit, not a one-off trick.

5. Hands-on Exercise

Hands-on

Rewrite three vague prompts, then prove few-shot changes the output

Turn today's four techniques into muscle memory by applying them to your own real prompts, not toy examples.

Part 1 — Fix your own prompts:

  1. Find (or write) three prompts you'd realistically send Claude for your own work — one for writing, one for analysis, one for code or data.
  2. For each, rewrite it to be clear and direct (explicit format, length, audience, constraints) and add relevant context (who it's for, what happens with the output).
  3. Run the before and after versions and compare. Note the single biggest difference in the output for each pair.
Hint

If you're struggling to find a real prompt, use one from a task you did manually this week — an email you wrote, a summary you had to produce, a small script you wrote by hand.

Part 2 — Prove few-shot changes behavior:

Pick a classification or formatting task (sentiment, urgency, extracting a field, converting to a specific format).

  1. Run it zero-shot (instructions only) on 3-5 inputs and note the output format Claude chose on its own.
  2. Add 2-3 examples showing your exact desired label set and format, including one edge case.
  3. Re-run the same 3-5 inputs and compare format consistency and edge-case handling before and after.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

What's the practical test for whether a prompt is "clear and direct enough"?

Whether someone with no context, reading only the prompt, would produce what you actually want. Anywhere they'd have to guess — format, length, tone, audience, constraints — is a gap Claude has to guess at too, and belongs explicitly in the prompt.

Q2

What does adding context (beyond the instruction itself) actually change about Claude's output?

It lets Claude make better judgment calls on everything the instruction doesn't explicitly cover — like which details in a document count as "important" for a given reader and purpose. The same instruction with different context can correctly produce very different outputs.

Q3

Why do good few-shot examples need to include edge cases, not just obvious ones?

Obvious examples only show Claude how to handle cases it would likely have gotten right anyway. The value of few-shot is showing how ambiguous or borderline cases should be resolved — that's exactly where a model left to guess is most likely to diverge from what you actually want.

Q4

When is it worth wrapping parts of a prompt in XML tags instead of writing plain paragraphs?

Once a prompt has multiple distinct parts — reference material, examples, instructions, formatting rules — that plain prose could blur together. Tags remove ambiguity about which text is content to act on versus an instruction to follow, which matters most on long or multi-part prompts.