How to write a skill that does not invent things

Hallucination is mostly a design problem, not a model problem. Remove the situations where inventing is the only option left.

A model invents when it has been asked a question it cannot answer and given no acceptable way to say so. Most of the fix is removing those situations, not instructing the model to be careful.

1. Give it an out, explicitly

The single highest-return line in most skills:

If the information is not in the provided documents, say "I don't have that" and stop. Do not fill the gap from general knowledge.

Without it, "answer the question" is the only instruction present, so the model answers. With it, there are two acceptable outcomes and one of them is cheap.

Then check that the out is actually reachable. If your prompt also says "always provide a recommendation", you have written a contradiction, and the model will resolve it by inventing. Read your instructions for conflicts before blaming the model.

2. Separate retrieval from generation

The most common cause of a confident wrong answer is that nothing was retrieved and the model carried on regardless.

Make the shape explicit: fetch first, and if the fetch returns nothing, that is the answer. In a tool-using skill, a lookup that misses should return an error result the model can read and act on — not an empty string that looks like a valid, empty answer.

3. Never let it do arithmetic that matters

Anything that must be right — totals, margins, dates, counts — is computed by code and handed to the model as a value. A number generated as text is a guess that happens to be plausible.

This is the same rule as making skills deterministic, and it is the one people concede in principle and violate in practice, usually by pasting a table into the prompt and asking for "the total".

4. Ask for the source alongside the claim

Require each substantive statement to carry where it came from — a document title, a field name, a record id.

This does two things. It makes an unsupported claim visible to a reviewer at a glance. And it measurably reduces invention, because a claim that needs a citation is harder to produce from nothing than a claim that stands alone.

5. Constrain the output shape

Free prose invites elaboration. A fixed structure does not:

Finding:
Evidence (quote or field):
Confidence (high / medium / low):
What would change this:

"What would change this" earns its place — it forces the model to state the condition under which it is wrong, which is very hard to do about something you made up.

6. Prefer narrow tools over wide context

Handing over a wide table and asking a question invites the model to compute. Handing over revenue_by_period(customer, from, to) does not. Narrow, typed, well-named tools make the correct path the easy path — the model chooses which operation, the code performs it.

7. Watch for the three high-risk shapes

Invention concentrates in predictable places:

Shape	Why it goes wrong
"Summarise these documents" where one is missing	Absence is invisible; the summary reads complete
Any question about a date, deadline or version	Highly specific, highly plausible, rarely retrievable
"What does the policy say about X" where X is not covered	The model reasons about what a policy would say

For each, decide in advance what the skill does when the answer is not there.

What "does not hallucinate" honestly means

It does not mean zero. It means the failure mode has moved from inventing an answer to saying it does not know — and that you can tell the difference from the output. If you cannot tell which you got, you have not improved reliability, you have only improved tone.

That is why this pairs with a test set. Persuasion is not evidence.