Forward-deployed / Learning zone
Prompt engineeringa standalone module
Lesson 02

The anatomy of a prompt

TL;DR

A prompt that works reliably is not one clever sentence — it names six things on purpose. Role (who the model is playing), task (what to do), context (the material to work from), constraints (what to avoid), format (what the output should look like), and examples (what "good" looks like when you can show it). Beginner prompts tend to have one or two of these, implicit and mixed. The upgrade to "power-user" is not a longer prompt — it is a prompt that hits each of the six on purpose, in an order the model can follow. Anthropic's own prompt engineering guide organizes its advice around exactly these dimensions, and every technique in the rest of this module — few-shot, chain-of-thought, tool use — is a specialized way of filling one of them.

🎯 For the AI PM (or coding-agent user)

Why it matters — Prompts fail one of these six ways more often than they fail for lack of cleverness. Naming the missing part is faster than rewriting the whole thing.

What it changes in your decisions — You treat any prompt template your team ships as a checklist against these six parts. You review prompts the way you review a PRD — is the role explicit, is the format specified, are examples present.

Ask yourself — "Which of the six parts is this prompt leaving to the model to guess?"

Risk if ignored — A prompt that "worked in the demo" ships to production and drifts wildly, because the parts you left implicit got interpreted differently at scale.

The mental model

The six parts, in order

Role first, examples last · order matters, each part inherits from the one before

Every technique later in this module is a specialized way of filling one of these six.

Role who is the model?
Task what to do
Context material to work from
Constraints what to avoid
Format what the output looks like
Examples what "good" looks like
Output

The order matters. Role first, so every later instruction inherits its framing. Task next, so the model knows what to do before it hears what to avoid. Context after that, so the material sits in the model's working memory when it starts. Constraints before format, so the format spec is scoped by what's allowed. Examples last — because examples are the strongest signal, and they anchor everything above them.

The six parts, one line each

A worked pass: from one-liner to production prompt

The one-liner:

Summarize this article for me.

What's missing: role (whose lens?), task (what kind of summary — TL;DR? key points? counter-arguments?), constraints (what to leave out?), format (bullets? paragraph? JSON?), examples (what does "good" look like?).

The upgrade:

You are a research assistant to a senior product manager. Read the article inside <article>...</article> and produce a summary the PM can skim in 30 seconds.

Constraints: do not add facts not in the article. Do not soften the article's claims.

Format: three sections — what it argues (1 sentence), the strongest evidence (2-3 bullets), what the PM should do about it (1 sentence).

Example: <example> [one worked case here] </example>

The upgraded prompt is longer. It's also repeatable. The one-liner gets a good output on a good day. The upgraded prompt gets the same shape of output every day, by every user, until the shape itself needs to change.

Tradeoffs

Failure modes

Practitioner checklist