Use Examples and Output Formats to Make Prompts More Predictable

The idea

A prompt is the instruction and information you give an AI model. A common developer request might be: “Write a commit message for this change.” It sounds clear, but it leaves important choices unstated. Should the answer use Conventional Commits? Should it mention a scope? Should it be one line or include a body?

Instead of hoping the model infers those choices, show it a few small examples and name the required output format. This approach is called few-shot prompting: the prompt contains a small number of examples before the new task. Anthropic describes examples as a reliable way to steer format, tone, and structure, and recommends explicitly specifying the desired format and constraints. Source

Plain English: Do not only describe a good answer. Show two or three small versions of one, then ask for the next answer in the same shape.

For recurring work, examples turn your expectation into something visible. They can show the level of detail that “concise” means to your team. They can also show fields that must always appear, such as a severity and suggested fix in a review note.

Each example is an input-output pair: a sample input followed by the result you want for that kind of input. Choose pairs that resemble the real task. Use some variation when it matters, such as a bug fix and a new feature. Anthropic recommends examples that are relevant, diverse, and structured so that the model can distinguish them from the instructions. Source

When a prompt has several parts, label them clearly. XML tags are one readable option: <instructions>, <examples>, and <input> visually separate material. Anthropic documents XML-style tags as a way to separate instructions, context, examples, and input in complex prompts. Source

A small example

Example: You want a draft Conventional Commit message from a short change description. A weak request is:

“Write a Conventional Commit message for: cache failed profile requests.”

A more directed prompt could be:

<instructions>
Return exactly one Conventional Commit message.
Format: type(scope): short imperative summary
No body. No markdown.
</instructions>

<examples>
Input: add retry handling to the payment client
Output: feat(payments): add retry handling

Input: correct the expiry check for session cookies
Output: fix(auth): correct session expiry check
</examples>

<input>
cache failed profile requests
</input>

The examples establish how short the summary should be and how scopes are written. The format rule states what is required for this new result. Neither part proves that the suggested message is semantically perfect. They simply make the requested shape clearer.

Templates can serve a similar role when a format must be strict, and Anthropic’s guidance uses input/output pairs where task quality depends on seeing examples. Source

Try it

Spend five minutes improving one prompt you already use. Pick a small repeatable task: turning bug reports into issue summaries, drafting test cases, or producing review notes.

First, write down the fields you need. For an issue summary, that might be title, observed behavior, expected behavior, and reproduction steps. Next, add two realistic input-output pairs. Make one ordinary and one slightly different case. Finally, place the new input after the examples and ask for exactly those fields.

Compare the response with the result from your original vague request. Check whether every field appears, whether the detail level fits, and whether the answer added material you did not request. Keep the examples only if they improve the task you actually have.

Watch out

Examples guide an answer; they do not guarantee that its facts, code, or tests are correct. Review generated material and run normal checks before relying on it.

Also, prompting with examples is not the same as machine-enforced structured output. A schema is a formal definition of allowed data fields and values. Examples and text instructions may encourage a JSON-like response, but the model can still omit a field or add extra text. If downstream software requires strict validity, use validation or a structured-output mechanism in addition to the prompt.

Avoid copying examples that contain accidental habits, such as an incorrect scope or irrelevant explanation. More examples are not automatically better: they can consume context and introduce conflicting patterns. Prefer a few relevant, clearly separated examples. Finally, make ambiguous rules explicit. “Keep it brief” is weaker than “return one line with no body.”