Structure

The guidance here is unusually blunt for a field this young: separate a prompt into distinct sections, marked with markdown headers or XML tags. <background_information>, <instructions>, ## Tool guidance, ## Output description.

Two reasons, and only one of them is about the model.

Models read long windows unevenly — strong at the beginning, strong at the end, weakest in the middle. Structure gives the middle landmarks.

The other reason is that you will edit this prompt fifty times. An undifferentiated slab has no seams, so every change is a change to the whole thing, and the way people cope is by appending. That is how the 600-token prompt in module one came to exist: not one bad decision, but forty small ones with nowhere good to put them.

High-performing prompt templates converge on a four-part shape: a role, slots for injected content, numbered instructions, and a constrained output format.

The last part carries more weight than the others. An unspecified output shape is re-invented on every call, which means anything downstream must parse prose, and prose that varies. Naming the shape — a JSON schema, named markdown sections, a fixed field list — converts an unbounded generation problem into a filling-in problem.

One caveat that comes free with it: a schema pressures a model to fill every field, and inference is how it fills them. So a contract that demands five sections needs an explicit escape — say what to do when a field has no support in the evidence. Otherwise the structure you added for rigour becomes a machine for producing confident filler.