Prompt engineering, the basics

A prompt is any text you send to the model. That's it. But the way you organize that text has a massive effect on the quality of the response. Prompt engineering is the craft of writing prompts that get consistent, high-quality outputs. It's less about magic incantations and more about being explicit about what you want.

Almost every good prompt has four pieces: (1) role/context — who Claude is playing and any persistent rules; (2) the task — what specifically to do this turn; (3) the input — the data or content to act on; (4) the output format — what the response should look like. Miss any one and you get worse results.

Bad: 'summarize this'

Good:
[system] You are a legal analyst. Be concise and cite exact clause numbers.
[user] <task>Summarize the termination provisions.</task>
<contract>{...}</contract>
<format>Bullet points, one per clause, ≤ 15 words each.</format>

System prompt: persistent role, rules, and reference material that apply to every turn. User message: the specific task and input for this turn. Rule of thumb: if it should apply to turn 47 the same as turn 1, it goes in system. If it's about this specific request, it goes in user.

One well-chosen example is worth many paragraphs of instructions. When you want a specific format, tone, or edge-case behavior, include 2–5 examples in the prompt showing input → desired output. The model matches the pattern more reliably than it follows abstract descriptions.

<example>
  <input>Order 123 arrived damaged</input>
  <output>{"category": "return", "urgency": "medium"}</output>
</example>
<example>
  <input>Fire alarm going off in warehouse</input>
  <output>{"category": "emergency", "urgency": "critical"}</output>
</example>

Nobody writes a perfect prompt on the first try. Treat prompts like code: version them, run them against test cases, measure results, iterate. If you're doing 'vibes-based prompt tuning' (change wording, look at one output, ship), you're guessing. Build a small eval set (20+ examples) and grade every change against it.

Being vague ('write a nice email'). Piling on negative instructions ('don't do X, don't do Y'). Bloating the system prompt with information the model doesn't need every turn. Forgetting the output format. Assuming the model knows domain context it doesn't have.