prompt-engineeringlisted

# 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 1. **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. 2. **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. 3. **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. 4. **Turn unknowns