Say what shape the answer should take

Ask a model to extract some data and it will happily give you a paragraph about the data. Not because it misunderstood — because you never said what shape you wanted, and prose is the default.

Extract the invoice totals from the supplier statement below for the finance team.

The task here is unambiguous. The verb is right, the object is right. And you will still get something like "I found three invoices in the statement. INV-104 is for £82.50, while INV-105..." — perfectly correct, and completely useless if you were going to feed it into a spreadsheet.

Prose is the default, and the default is rarely what you want

Models are trained overwhelmingly on prose written for humans. Absent any instruction, that is what they produce. This is fine when a person is going to read the answer, and actively costly the moment anything else is:

• You wanted JSON, and now you are writing a parser for English.
• You wanted three bullets, and got four paragraphs you have to skim.
• You wanted a table, and got a table described in words.
• You wanted just the code, and got the code wrapped in three paragraphs of explanation you did not ask for.

Each of those is a round trip you pay for in time, and often in a second API call.

Name the shape, and show it

Extract every invoice total from the statement below.

### Output format
Return JSON: [{"invoice": "string", "total": 0.00}] and nothing else.

### Example
[{"invoice": "INV-104", "total": 82.50}]

### Statement
"""
INV-104  82.50
INV-105  19.00
"""

Three separate things are doing work here, and they compound.

The format is named. Return JSON: [{"invoice": "string", "total": 0.00}] removes every ambiguity about structure — the key names, the nesting, the types.

"and nothing else" is not redundant. Without it, models often wrap valid JSON in a friendly sentence, or a markdown code fence, and now your JSON.parse throws. This four-word clause is the difference between a parser that works and one that needs a regex to clean up first.

The example pins down what the description cannot. Is total a string or a number? Does it carry a currency symbol? The schema line suggests an answer; the example settles it. This is why the format check and the example check so often fire together — they are two halves of the same instruction.

What counts as a format

More than you might think. Any of these is a format instruction, and any of them beats silence:

• Structure: JSON, CSV, a markdown table, a bulleted list, a single code block.
• Length: under 200 words, exactly three bullets, one paragraph, no more than 15 words per bullet.
• Composition: "a title, then three sections, then a conclusion".
• Exclusion: "no preamble", "no summary at the end", "code only, no explanation".

That last category is underrated. Half the frustration with model output is not that the content is wrong — it is the "Certainly! Here's the summary you requested:" wrapped around it. One line — "Return the summary only, with no preamble" — deletes that forever.

If you use structured outputs, still say it

Most APIs now support a schema that guarantees the response shape. Use it — it is strictly better than hoping.

But keep the instruction in the prompt anyway. The schema constrains the shape of the output; it does not tell the model what the fields mean, or which of two plausible readings of your data to pick. A schema will happily give you a perfectly-formed JSON object full of the wrong values.

Every check in this article ran live in your browser. The same nine run on any prompt you paste in, for free.