prompt-engineeringlisted

# Prompt Engineering Reliable model behavior comes from **specificity and structure**, not magic words. A good prompt reads like a precise spec: it states the role, the task, the constraints, shows examples, and pins the exact output shape. This package is the deep reference; technique detail lives in `references/`, worked prompts in `examples/`, and a runnable output check in `scripts/`. ## The anatomy of a strong prompt A production prompt has up to six parts, in roughly this order: 1. **Role / context** — frame the model ("You are a senior SQL reviewer…"). Sets vocabulary and standards. 2. **Task** — the single, clear instruction. 3. **Constraints** — what to do and explicitly what *not* to do. 4. **Examples (few-shot)** — demonstrations of input→output for tricky or format-sensitive tasks. 5. **Output format** — the exact shape (JSON schema, sections), so output is parseable. 6. **The data** — the user input, fenced off from the instructions. Not every prompt needs all six, but reach for them in this order as reliability demands grow. ## Core techniques - **Be specific.** Vague prompts produce vague, inconsistent output. "Summarize" → "Summarize in 3 bullet points, each under 15 words, focusing on action items." - **Show, don't just tell.** For format-sensitive or nuanced tasks, 2–3 few-shot examples outperform paragraphs of description. See `references/techniques.md`. - **Structured output.** When you need to parse the result, *require* structure (JSON schema)