The anatomy of a good prompt

AI Foundations introduced the basics of a prompt: give context, state a task, and describe the format you want back. That was the surface. This lesson goes one level deeper: what each of those three ingredients is actually doing for the model, and why leaving one out produces a specific, predictable kind of weak answer.

Context: closing the gaps the model would otherwise guess at

A model has no memory of who you are, what you already tried, or why you are asking. Every gap you leave gets filled with a generic assumption. Context is the information that closes those gaps: who the output is for, what you already have, what has already failed, and any constraints that matter, such as a budget, a deadline, a required tool, or a style guide. The rule of thumb is simple: if a new coworker would need to know it to do the task well, the model needs it too.

Task: one clear instruction, stated as an action

The task is the actual instruction: the verb and the object. "Write," "summarize," "debug," "compare," "translate." A strong task is singular and concrete. If a request bundles several different asks into one vague sentence, such as "help me with my resume," the model has to guess which of a dozen possible kinds of help you want. Naming the exact action, such as "rewrite the summary section to fit in three lines," removes that guesswork entirely.

Format: describing the shape of the answer, not just its content

Format is everything about how the answer should be packaged: length, structure (bullet list, table, plain prose, code), tone, and language. Two prompts can ask for the exact same content and get very different, equally correct answers, one a wall of text and one a scannable list, because only one of them specified the format. Format is not decoration. It is the difference between an answer you can use right away and one you have to rework before you can use it.

Ask a hundred people why an AI answer disappointed them, and the honest reason in most cases is not that the model is weak. It is that the prompt was vague, and a vague prompt admits many different valid answers. The model picked one of them. It probably was not the one you had in mind.

What vagueness actually looks like

Vague prompts lean on words that feel specific but are not: "a few examples," "make it better," "more professional," "the usual format." Each of those phrases has dozens of reasonable interpretations. "A few" could mean two or ten. "Better" could mean shorter, funnier, more formal, or more detailed. Without more to go on, the model has to pick an interpretation, and it will not always pick yours.

There is no secret phrase

New users often go looking for a magic incantation: a special phrase, a threat, a bribe, or a claim that something important depends on the answer. None of that is necessary. What actually works is naming exactly what you want in plain words. Specificity is not a trick. It is simply giving the model less to guess about, and a model with less to guess about lands closer to your intent on the first try.

A quick specificity checklist

• Replace fuzzy quantities ("a few," "several") with an exact number.
• Name the deliverable directly ("a bullet list," "a function," "a subject line") instead of "something."
• Define any adjective that could mean several things ("professional," "punchy," "clean") in your own words.
• Say what to leave out, not just what to include, if there is an obvious wrong turn to avoid.

Two prompts can share the exact same task and format instructions and still produce very different answers, because of one more lever: who the model is acting as, and who is going to read the result. Role, audience, and tone are three closely related dials that shape the voice of an answer rather than its content.

Role: who the model should act as

Assigning a role tells the model which lens to evaluate the task through. "Review this code" gets a generic pass. "You are a senior security engineer reviewing this code for vulnerabilities before it ships" gets a review that actually looks for injection risks, unsafe defaults, and edge cases, because that is what a security engineer would prioritize. The role does not add facts the model did not already know. It changes which of that knowledge gets applied, and how it gets framed.

Audience: who the answer is for

Audience shapes vocabulary and depth. The same explanation of how vaccines work reads completely differently depending on whether it is written for a curious 10-year-old or for a doctor. Naming the audience lets the model choose the right level of detail and the right words on the first attempt, instead of you rewriting it afterward.

Tone: how it should sound

Tone is the third dial: formal or casual, terse or warm, encouraging or blunt. It is worth naming directly rather than leaving it to guesswork, especially for anything that will be read by someone else, such as an email or a support reply. "Keep it warm and brief" and "keep it direct and no-nonsense" describe the same task with very different results.

Sometimes the fastest way to get the output you want is not to describe it in more words, but to show one. This lesson covers the difference between asking cold and showing an example, and when the extra step of writing an example actually pays off.

Zero-shot: instructions with no example

A zero-shot prompt gives instructions and nothing else: no sample of the output you are after. Most everyday prompts are zero-shot, and for straightforward tasks that is perfectly fine. "Write a subject line for this email" is zero-shot, and it works because the task is common enough that plain instructions are unambiguous.

Few-shot: show, then tell

A few-shot prompt adds one or more example input-output pairs before the real request. Instead of describing a format in the abstract, you show it directly.

Turn each product name into a tagline.

Product: Solar Charger
Tagline: Power that never plugs in.

Product: Noise-Cancelling Headphones
Tagline: Quiet, on demand.

Product: Standing Desk
Tagline:

The example pairs teach the pattern (product in, short punchy tagline out) far more precisely than a written description of "short and punchy" could. The model completes the pattern instead of guessing at what "punchy" means.

When examples earn their cost

• The output has a specific shape that is hard to describe in words, such as an exact JSON structure or a particular data layout.
• You need a voice or style matched precisely, such as a brand tone or a specific documentation format.
• The task is genuinely ambiguous and a written instruction keeps producing the wrong interpretation.
• You are generating many similar items and need them to stay consistent with each other.