Structured prompting

Why structure matters

Once prompts grow past a few sentences, they start mixing several kinds of content: the task, background context, rules, examples, the actual input data, and the output format. Written as one paragraph, these blur together. The model may treat part of your pasted email as an instruction, or miss a rule buried in the middle.

Structured prompting means giving each kind of content its own clearly labelled place. It helps the model, and it helps you: a structured prompt is far easier to read, debug, reuse and hand to a teammate.

In the first version, "Ignore any previous instructions" sits in the same stream as your real instructions. In the second, it's clearly inside the <email> block, and the rules say that content is data. This reduces confusion — though, as you'll see in the next lesson, it isn't a complete defence against prompt injection.

The main tools

Headings and sections

Markdown-style headings (## Task, ## Context, ## Rules, ## Output format) are simple and readable. A common, effective order is:

1. Role or goal (one or two lines)
2. Context the model needs
3. The task itself
4. Rules and constraints
5. Examples (if any)
6. Input data
7. Output format

With long documents, many people find it works well to put the large data first and the specific question or instructions near the end, so the request is fresh when the model starts writing. Test both placements for your case.

Delimiters

Delimiters are markers that fence off a block of content: triple quotes, --- lines, or triple backticks. They answer one question for the model: where does this piece start and stop?

XML-style tags

Tags like <document>, <example> and <instructions> are particularly handy because:

• They have clear opening and closing markers.
• You can name them meaningfully and refer to them: "Using only the facts in <contract>, …".
• They nest: <examples><example>…</example></examples>.
• Your code can easily wrap inputs in them, and parse tags in the output.

There's nothing special about specific tag names — the model isn't reading a schema. Choose descriptive names and use them consistently.

Templates

A template is a structured prompt with placeholders for the parts that change. It's how you go from a one-off prompt to something reusable across a team or an application.

You are reviewing a pull request for {{repo_name}}.

<guidelines>
{{team_review_guidelines}}
</guidelines>

<diff>
{{diff}}
</diff>

Review the diff against the guidelines. Return:
1. Blocking issues (bugs, security, broken guidelines) — cite file and line.
2. Non-blocking suggestions.
3. A one-sentence overall assessment.
If there are no blocking issues, say "None" for section 1.

In code, you'd fill those placeholders programmatically. Keep the fixed instructions stable and only vary the slots — that makes it much easier to evaluate changes later.

Structuring the output, too

Structure isn't just for input. Asking for a defined output shape — labelled fields, a table, or JSON — makes responses consistent and machine-readable. For JSON, give the exact keys and types, and say what to do when a value is unknown (e.g. null). Many APIs also offer dedicated structured-output or JSON modes; where available, those are more reliable than prompt wording alone.

Don't over-engineer

Structure should clarify, not decorate. A two-line request doesn't need six headings. Signs you've overdone it: empty sections, duplicated rules in several places, or tags nested so deeply you can't tell what's what. Start with the minimum (instructions vs data, plus output format) and add sections when you actually need them.