The slots of a prompt

Most prompts fail not because the model is incapable, but because the prompt was missing something the model needed, or the model was free to interpret the request in a way the writer never intended. Both have the same solution: structure the prompt so each piece of information has a clear place and purpose.

A prompt can contain up to five slots: role, instruction, context, examples, and output format. Only the instruction is mandatory.

The five slots

Role

The role slot tells the model what perspective or persona to adopt before it reads anything else. In a chat API call it typically appears as the system message, but it can also be the opening line.

You are a senior software engineer reviewing code for correctness and clarity.

The role constrains the model’s vocabulary, assumed knowledge level, and tone. Without one, the model adopts a neutral general-purpose stance. That is sometimes what you want, but often not, and adding a role is the lowest-effort way to shift the default.

Instruction

The instruction slot is the task itself. It is the only required slot, because without it the model has nothing to do. Every other slot exists to support it.

Identify the bugs in the following function and explain each one.

A good instruction is unambiguous about what action to take and what the output should cover. Vague instructions like “help me with this code” leave the model to guess the action, differently on different runs.

Context

The context slot supplies background information the model does not have on its own: the document being summarised, the data being analysed, facts relevant to the task that are not common knowledge.

The function is part of a payment processing service. It runs on every checkout event.

Context is not the instruction. It does not tell the model what to do; it tells the model what it needs to know to do it well. Conflating the two is a common source of poorly structured prompts.

Examples

The examples slot shows the model what a correct output looks like. This is the mechanism behind few-shot prompting, covered later in its own chapter. A concrete example communicates output expectations more precisely than a description can, because it removes the gap between what you describe and what you actually want.

Here is an example of the format I want:

Bug: Off-by-one error on line 12.
Impact: The last item in the list is never processed.
Fix: Change `< length` to `<= length`.

Output format

The output format slot specifies the structure of the response: a numbered list, a JSON object, a table, a single sentence. Without it, the model chooses its own structure. That choice is usually reasonable, but reasonable is not the same as what you wanted.

Return your findings as a numbered list. Each item must follow this structure:
Bug / Impact / Fix

Placing the output format at the end, right before the model starts generating, is deliberate. We will see why in the next lesson.

Slots are not always separate sentences

In practice the five slots often merge into a single paragraph. A prompt does not need to label them or separate them with line breaks; what matters is that the information each provides is present somewhere.

The diagram shows the slots in their natural order: role frames what follows, instruction states the task, context and examples support it, and output format comes last to constrain what the model produces.

What happens when slots are missing

Omitting a slot is not always a mistake. A simple factual question needs only an instruction; a creative task may need no context. But when you omit a slot the task requires, the model fills the gap with whatever its training makes most probable, which is not necessarily what you intended. The errors are subtle because the output looks reasonable. It just is not right.

In the next lesson, we’ll look at how the position of information inside a prompt affects how strongly the model attends to it, and why slot order is not arbitrary.