Prompt engineering
A prompt is a specification. Vague specs get confident garbage; the fix is
almost never "more words", it is the right words in the right structure.
Method
- Write the success criteria first. What does a correct output contain,
in what shape, and what would make it wrong? If you cannot check an
output, you cannot prompt for it.
- Pick the technique for the task type:
- Classification / extraction → 2-5 worked examples (few-shot) showing
input → exact expected output, including one tricky case. Examples
teach format and edge handling better than any description.
- Reasoning / math / multi-step → instruct step-by-step thinking before
the answer, and separate the reasoning from the final answer so it can
be parsed.
- Creative / stylistic → role and audience ("you are a..., writing
for..."), two or three constraints that define the voice, and one example
of the tone if you have it. Constraints beat adjectives.
- Structured output → show the exact schema with a filled example.
State what to do when a field is unknown (empty string?
null? omit?)
or the model will invent.
- Structure the prompt in blocks, clearly delimited: role/context →
task → rules → examples → the input (fenced or tagged, e.g.
<document>...</document>) → output format. Data always arrives below
instructions and marked as data, so instructions embedded in the data
stay data.
- Turn unknowns into named variables.
{audience}, {tone},
{max_length}: never invent a specific the user did not give. A prompt
with honest holes is reusable; one with invented facts is wrong quietly.
- State the negative space. What to do when the input is empty,
contradictory, or outside scope ("say 'not found', do not guess"): the
unhandled edge is where hallucination lives.
- Test on the ugly cases, then tighten. Run the empty input, the
ambiguous one, the adversarial one. Every failure becomes either a rule
or an example. Prompts are debugged, not authored.
Settings guidance
Temperature ~0-0.3 for extraction, classification, and code; ~0.7+ for
divergent creative work. When output must parse, say so and set the format
and the temperature: one without the other fails intermittently, which
is worse than always.
Boundaries
No prompt fixes a task the model lacks the context or capability for:
missing information is fetched or asked for, not conjured. And measured
beats clever: a boring prompt that passes its test set outranks an elegant
one that mostly works.
1---2name: prompt-engineering3description: Build prompts that get accurate, reliably-shaped output from any LLM, choosing the right technique for the task. Use when writing, improving, or debugging a prompt.4---56# Prompt engineering78A prompt is a specification. Vague specs get confident garbage; the fix is9almost never "more words", it is the *right* words in the right structure.1011## Method12131. **Write the success criteria first.** What does a correct output contain,14 in what shape, and what would make it wrong? If you cannot check an15 output, you cannot prompt for it.162. **Pick the technique for the task type:**17 - *Classification / extraction* → 2-5 worked examples (few-shot) showing18 input → exact expected output, including one tricky case. Examples19 teach format and edge handling better than any description.20 - *Reasoning / math / multi-step* → instruct step-by-step thinking before21 the answer, and separate the reasoning from the final answer so it can22 be parsed.23 - *Creative / stylistic* → role and audience ("you are a..., writing24 for..."), two or three constraints that define the voice, and one example25 of the tone if you have it. Constraints beat adjectives.26 - *Structured output* → show the exact schema with a filled example.27 State what to do when a field is unknown (empty string? `null`? omit?)28 or the model will invent.293. **Structure the prompt in blocks,** clearly delimited: role/context →30 task → rules → examples → the input (fenced or tagged, e.g.31 `<document>...</document>`) → output format. Data always arrives *below*32 instructions and marked as data, so instructions embedded in the data33 stay data.344. **Turn unknowns into named variables.** `{audience}`, `{tone}`,35 `{max_length}`: never invent a specific the user did not give. A prompt36 with honest holes is reusable; one with invented facts is wrong quietly.375. **State the negative space.** What to do when the input is empty,38 contradictory, or outside scope ("say 'not found', do not guess"): the39 unhandled edge is where hallucination lives.406. **Test on the ugly cases, then tighten.** Run the empty input, the41 ambiguous one, the adversarial one. Every failure becomes either a rule42 or an example. Prompts are debugged, not authored.4344## Settings guidance4546Temperature ~0-0.3 for extraction, classification, and code; ~0.7+ for47divergent creative work. When output must parse, say so and set the format48*and* the temperature: one without the other fails intermittently, which49is worse than always.5051## Boundaries5253No prompt fixes a task the model lacks the context or capability for:54missing information is fetched or asked for, not conjured. And measured55beats clever: a boring prompt that passes its test set outranks an elegant56one that mostly works.
Amey-Thakur