Prompting and context
Prompting
Clear instructions, examples, structure and chain-of-thought: prompting as specification writing.
A prompt is everything the model reads in one call: system instructions, chat history, retrieved documents, tool schemas and the task itself. When a production answer is bad, the cause is usually the prompt. The model is rarely "dumb." The job was under-specified, the same way a vague ticket under-specifies work for a new teammate.
Think of prompting as writing a spec for a capable colleague who has never seen your product. They know only what you put in front of them. Word tricks matter less than coverage and clarity.
Why this matters: the model samples its answer (see sampling). A clear prompt does not remove that randomness, but it makes the good answers far more likely.
Concepts in this section
Read them in order. Each one builds on the one before.
| Step | Concept | What it answers |
|---|---|---|
| 1 | Prompts as specifications | What must a prompt say before the model can do the job? |
| 2 | Prompt structure | Where do the rules, data and question go? |
| 3 | Few-shot examples | When do examples teach better than rules? |
| 4 | Chain-of-thought | When should the model reason before it answers? |
Cross-cutting common mistakes
- Vague success. "Be helpful, accurate and concise" cannot be checked, so every answer can claim to pass.
- Contradictory instructions. The model invents a compromise you never wanted. Resolve the conflict and state the winning rule once.
- Caps-lock threats. "YOU MUST NEVER..." adds noise. One clear rule with a reason works better.
- Asking for JSON and a chatty preamble at once. Parsers break. Use structured outputs when code reads the result.
- Editing prompts from one bad example. You fix that case and break three others. Measure first.
Iterate with evals, not vibes
Prompt changes feel subjective, but you can measure them.
- Build a small golden set of 50 to 200 cases that cover the labels and failure modes you care about.
- Change one factor at a time: the wording, the examples or the output schema.
- Score with code where you can (valid JSON, required fields, regexes). Use humans or an LLM judge for the rest.
- Version the prompt, like code, and log the version id on every production trace.
Without versions, you cannot find the change that caused a regression. Without a golden set, a prompt change is a guess.
Key takeaways
- A prompt is a spec: goal, inputs, constraints, output contract and success criteria.
- Keep durable rules in the system prompt and per-request data in the user message.
- Few-shot examples teach judgment. Diversity matters more than count.
- Use reasoning for multi-step work. Skip it for simple format changes.
- Measure every prompt change against a fixed set of cases.
Further learning
Anthropic's prompt engineering overview covers structuring instructions, examples and long-context layouts.
Prompt engineering overview (Claude docs)Learn when prompt engineering is the right solution, and find Claude prompting techniques and interactive tutorials.Claude Platform DocsLilian Weng's survey is a clear map of the classic techniques and when they help.
Prompt Engineering (Lilian Weng)Prompt Engineering, also known as In-Context Prompting, refers to methods for how to communicate with LLM to steer its behavior for desired outcomes without updating the model weights. It is an empirical science and t…lilianweng.github.ioStart with the first concept page: prompts as specifications.
Related
Structured outputs
Getting reliable JSON: schemas, constrained decoding, validation and repair.
Context engineering
Deciding what goes into the context window: ordering, compaction, memory and long context vs retrieval.
Evaluating LLM apps
A fixed set of inputs plus a way to score outputs, so you can tell whether a change helped.