The Anatomy of a Prompt That Actually Works

People hoard prompts like cheat codes — a folder of "god-tier" phrases they paste and pray over. That is backwards. A prompt is not a magic spell, it is a brief. And every brief that works has the same parts.

Anthropic's own guidance puts it well: treat the model like "a brilliant but new employee who lacks context on your norms and workflows." A new hire that sharp doesn't need secret words. It needs a proper brief. Once you can name the parts of one, you stop guessing — a weak output is almost always one missing part, and you can point straight at it.

The five parts

The two people skip most are Context and Constraints — and those are exactly the two that decide whether the answer is usable.

The test for whether your prompt is done

Here is the fastest gut-check I know. Imagine handing your prompt — nothing else, no follow-up conversation — to a sharp colleague on their first day. Could they do the task? If not, neither can the model. That is the whole reason Anthropic tells you to picture a brilliant-but-new employee: the model has the skill, but zero of your context until you supply it. When the output lets you down, stop fighting the output — go back to the brief and find the part you left thin.

A skeleton you can reuse

You don't rebuild this from scratch each time. Fill the brackets, delete the guidance, send. It costs about ninety extra seconds over a one-line prompt, and it changes the output completely.

Act as [the specialist this task actually calls for — "a staff engineer who
has reviewed thousands of PRs," not just "a developer." Pick the judgment you
want, not only the knowledge].

Here's the situation: [everything the model can't know without you — the stack,
who the output is for, what's at stake, what already went sideways. Three to six
sentences. This is the layer generic answers die on].

Here's what good looks like: [paste one real sample in your style — a past
review, a doc, a message. Then say: match this shape and voice, don't sand it
down to an average].

Rules:
- Never [the failure you keep seeing: "leave nitpicks", "invent an API", "run past 200 words"]
- Always [the thing you always want: "lead with the highest-severity issue", "show the diff"]
- [scope or length limit: "top 5 findings max", "one screen of output"]

Give me:
1) [the thing itself]
2) [variations where useful: "two subject lines", "a terse and a verbose version"]
3) [the artifact you'll reach for right after: "the 3 objections a reviewer will
   raise and how I'd answer each", "a checklist before I merge"]

Show, don't tell — the line that does the most work

"Professional but friendly" tells the model nothing; you can't measure it. An example can. This is the part most people never add, and it is the highest-leverage one. Anthropic calls it few-shot (or multishot) prompting and is blunt about it: examples are "one of the most reliable ways to steer Claude's output format, tone, and structure," and the recommendation is 3–5 that are relevant to your real case and varied enough that the model doesn't latch onto an accidental pattern. One real sample beats a pile of adjectives.

Three prompts, one skeleton

A code review. All five parts, because the stakes and the voice both matter:

Act as a staff engineer who reviews for correctness and blast radius before style.
Situation: this is a payments service in Go; the diff touches idempotency keys on
the refund path; it ships to prod Friday and I own the on-call.
Good looks like: [paste a past review of mine]. Match that: direct, one line per
finding, severity first.
Rules:
- Never flag formatting the linter already handles
- Always give a concrete fix or a diff, not just "consider refactoring"
Give me: 1) findings ranked by severity, 2) the one failure mode most likely to
page me at 3am, 3) the test I'm missing.

A messy incident, turned into a summary. Context-heavy — you paste the raw timeline and let Format do the shaping:

Act as an SRE writing a blameless postmortem.
Situation: [paste the Slack timeline]. Audience is eng leadership; they want
cause and prevention, not a play-by-play.
Rules: no blame, no jargon leadership won't know, under 300 words.
Give me: 1) a two-line summary, 2) root cause, 3) three action items with owners.

An architecture decision — where you drop a layer on purpose. A judgment call doesn't need your writing voice, so the example layer goes:

Act as a pragmatic architect who has watched teams over-engineer this exact call.
Situation: 20k daily users, spiky traffic, a 3-person team. Postgres vs. DynamoDB
for the primary store. We know Postgres; nobody has run Dynamo in anger.
(Skipping the example layer — a decision doesn't need my prose style.)
Rules: pick one in the first sentence; state your confidence and what would flip it;
if I'm asking the wrong question, say so first.
Give me: 1) your pick, 2) the strongest reason for and the strongest against,
3) what to measure in the first 30 days to know you were right.

That last one is the real lesson: the skeleton is a menu, not a mandate. Cut the layers a given task doesn't need — but never the ones it does.

Keep it where you'll actually reach it

A skeleton you have to hunt for is a skeleton you won't use. Keep it somewhere you can grab in five seconds — a snippet expander, a pinned note, or dropped into the tool's custom instructions (or a CLAUDE.md in your repo) so the assistant itself reminds you of the shape. Better still: keep one already-filled version for each task you do often — your review prompt, your standup-summary prompt — so you're editing, never starting from a blank box.

Why this beats memorizing tricks

Structure wins over magic phrases because of how these models actually work. Anthropic's interpretability research found the model is "combining independent facts to reach its answer rather than regurgitating a memorized response" — and that it plans ahead, assembling toward a destination rather than picking the next word blindly. There is no stored reply keyed to a special phrase. The answer is built from the material you hand over, so the gains come from handing over better material. That is all the five parts are: a checklist for better material.

This week

Take the last prompt that disappointed you. Do not rephrase it. Label which of the five parts it was missing, add only that part, and run it again. You'll be surprised how often one missing line was the whole problem.

Sources

• Anthropic — Claude prompting best practices
• Anthropic — Tracing the thoughts of a language model