conceptContext Engineering~1 min readUpdated 2026-06-07#prompt-engineering#prompts#structure

Anatomy of a good prompt

Good prompts aren't magic words; they're clear specifications. A reliable prompt usually has the same parts, whether you write them as prose or sections.

The components

  • Role / persona — who the model is acting as ("You are a senior security reviewer"). Sets tone and domain framing.
  • Task — the single, explicit objective. Ambiguity here is the #1 cause of bad output.
  • Context — the material the task operates on (the document, data, examples).
  • Constraints — what to do and avoid: length, style, what to skip, how to handle uncertainty ("if the answer isn't in the context, say so").
  • Output format — the exact shape expected (JSON, schema, headings, bullet list).
  • Examples — one or more demonstrations (few-shot) when the task is hard to describe but easy to show.

Principles that consistently help

  • Be specific and concrete — replace "summarize nicely" with "summarize in 3 bullets, ≤15 words each, no jargon."
  • Show, don't just tell — an example often beats a paragraph of instructions.
  • Put instructions and the most important context at the edges, not buried in the middle (lost in the middle).
  • Give an out — tell the model what to do when it can't comply, to curb hallucination.
  • One prompt, one job — split compound tasks (decomposition).

Pitfall

Over-stuffing a prompt with caveats can confuse the model as much as too little. Write the minimum that makes the task unambiguous, then test and trim.

Connects to: system prompts · few-shot · output format