The Anatomy of a Prompt: Instructions, Content, Examples, and Cues

What this slice covers

A prompt is not a sentence you type into a box. It is a small assembled structure, and the parts of it do different jobs. This note covers the named components of a prompt, what each one contributes, how they appear in a chat-style call to a Foundry model, and how to read a disappointing answer back to the component that was missing. Two neighbouring subjects are deliberately left out: prompt layout (ordering, separators, token budget) and grounding against your own data each get their own note.

The behaviour everything else sits on

Before the components make sense, hold one blunt fact about how these models work. A generative language model produces the continuation it judges most likely, given everything in front of it. When you ask a question and receive an answer, the model has not switched into a special question-answering mode — an answer is simply the most likely thing to follow a question. Microsoft's guidance makes this explicit with famous opening lines: give a model the first words of a well-known text and it continues the text.

That single idea explains a great deal of otherwise puzzling behaviour. It explains why a half-finished instruction gets completed rather than queried. It explains why a model produces a fluent, plausible citation that does not exist — a plausible citation is a likely continuation. And it explains why the shape of what you send matters as much as the content.

The five components

Instructions tell the model what to do. They are the most commonly used component and the one people underestimate, because instructions scale from a single clause to a structured list of requirements, and the detailed version usually wins. Compare "write a newsletter introduction" with a version that names the company, the event to mention, the tone, and the signature line: the second leaves far less to interpretation.

Primary content is the text the model is meant to process or transform — the passage to summarise, the sentence to translate, the transcript to classify. It is the object of the task. Primary content can be short, or hundreds of words, or structured data such as a table; models handle tabular input well and can answer questions over it.

Examples are input/output pairs showing the behaviour you want. One example is one-shot, several are few-shot, none is zero-shot. Examples do not retrain the model; they condition it for the current request only. They are unusually effective at pinning down a task the instruction cannot easily describe — such as which label vocabulary to use — and models will often infer a category that never appeared in your examples.

A cue is a fragment at the very end of the prompt that the model builds onto, jump-starting the output into a shape. Ending with a bullet marker or with a phrase like a key-takeaway opener steers both the format and the focus of what follows.

Supporting content is context that influences the answer without being the thing being processed: today's date, the user's name, a list of topics the reader cares about. Give a model a list of workshops and it lists workshops; give it the same list plus the reader's priority topics and it groups them under those topics.

How the components land in a chat call

In a chat-style API, you send an array of messages carrying roles — system, user, and assistant. Instructions naturally become the system message. Few-shot examples are supplied as example user and assistant turns after that system message, so the model sees a short fake conversation demonstrating the pattern. Primary content sits in the live user turn, and the cue goes at the very end of it. Nothing about the component model changes; only where each part is carried.

Diagnosing a bad answer by component

This taxonomy earns its keep when something goes wrong. Output is generic and unfocused: the instruction is too thin. The facts are right but the format is wrong: there is no cue and no stated output shape. The model ignores context you supplied: you mixed supporting content into primary content, or vice versa. Classification is inconsistent across runs: there are no examples. Rewriting the whole prompt at random is the beginner's move; changing one component and re-testing is the professional one.

Mistakes people make

The most common error is believing few-shot examples permanently change the model. They do not — the effect lasts exactly one inference. The second is padding instructions with adjectives instead of constraints; "be helpful and thorough" restricts nothing, while a list of required elements restricts a lot. The third is assuming a prompt that worked once will generalise; Microsoft is explicit that you still have to validate what the model produces.

One boundary matters for the exam and for real work: this component-based prompt-crafting guidance is aimed at conventional generative models. Microsoft does not recommend these techniques for reasoning models such as the gpt-5 and o-series families, which do more of this structuring internally.