A clear LLM prompt tells the model what to do, supplies the information needed for the task and defines an acceptable response. Instructions state the rules. Examples show how those rules apply. An output specification tells the model what the receiving person or program expects.
These elements work together. If an instruction says to return an unknown date as null while every example invents a date, the prompt teaches conflicting behaviour.
Write instructions that settle real decisions
Start with the task and its boundaries. “Extract the delivery date” is incomplete if a customer names a range, uses a relative date or mentions an unrelated appointment.
A more complete specification states the reference date, the timezone when relevant, how to interpret ranges and what to do when the meaning is unclear. Some of those decisions belong in product requirements before they belong in a prompt.
Extract the requested delivery date from the message.
Use the supplied reference date for relative dates.
For a date range, return the final date in the range.
Return null if there is no clear delivery request.
Do not treat an invoice date as a delivery date.
This prompt still needs the actual reference date and message. It also needs validation of the returned calendar date. Instructions establish the intended behaviour; they do not enforce it.
Use few shot examples to explain difficult boundaries
An example should pair a realistic input with the desired output. Cover distinctions that matter, including missing information.
Reference date: 2026-03-02
Message: Please deliver it by Friday.
Delivery date: 2026-03-06
Reference date: 2026-03-02
Message: Delivery any time between March 10 and March 14 is fine.
Delivery date: 2026-03-14
Reference date: 2026-03-02
Message: My invoice is due on Friday.
Delivery date: null
Reference date: 2026-03-02
Message: I may be away next week. Can we discuss delivery?
Delivery date: null
The final two examples distinguish a date mention from a definite delivery request. That distinction is more useful than several nearly identical positive examples.
Review the labels with someone who understands the task. A prompt can consistently imitate a mistaken example. Keep personal information out of demonstrations unless its inclusion is necessary and authorised.
Choose the example count through evaluation
A few shot prompt may improve with additional demonstrations, but the effect is task dependent. Many Shot In Context Learning studied larger demonstration sets and found benefits on selected tasks. That finding does not establish a default example count for every application.
Compare a zero shot baseline with a small set of carefully chosen examples. Add examples that address observed errors, then measure the effect on both those errors and ordinary traffic. Test example order when results appear sensitive to it.
Track token use alongside accuracy. A longer example set may be worthwhile for a difficult task but wasteful for a simple extraction. Dynamic example selection can help when a broad task contains many distinct cases, provided selection is also evaluated.
Specify output fields and missing values
A program needs more than “return JSON.” Specify each field, its type, its allowed values and how absence is represented.
{
"outcome": "callback_booked",
"minutes": 7,
"products": ["TRN200"],
"follow_up": "2026-03-09",
"summary": "A callback was agreed to investigate the download problem."
}
For this example, the prompt might allow three outcomes, require minutes to be a non negative integer and permit follow_up to be a date or null. A separate rule should prohibit inventing an outcome unsupported by the transcript.
The JSON string stays on one line to keep the example valid. An unescaped line break inside a JSON string would make the example invalid. Examples must satisfy the same schema as real output.
Use structured output when the interface supports it, then apply schema and business rule validation. A valid object can still contain the wrong date.
Arrange the prompt for the actual model and workload
Separate instructions, demonstrations and source material with clear labels. Use the provider's message roles where available. Labels and delimiters improve interpretation, but they do not create a security boundary around untrusted text.
A stable prefix can make repeated input eligible for prompt caching on supported services. Keep request specific material separate where that fits the task, and test the resulting order. Research on long context position effects is a reason to evaluate placement, not proof that one layout is always best.
For a practical review, check a normal input, an ambiguous input and an input with no answer. If a colleague cannot determine the expected output from the prompt, the model has been left to make an unstated product decision.