Prompt Engineering
Prompt engineering means giving the model input so that the output is reliable and useful. The golden rule for Claude: treat Claude like a smart new colleague who knows nothing about your context — spell everything out clearly.
4.1 Core techniques
| Technique | How | Why it works |
|---|---|---|
| Be clear and direct | Write the task, audience, format, success criteria | The model does not have to guess |
| Give context and the "why" | "This will go into text-to-speech, so do not use ellipses" | Claude understands the reason and generalizes |
| Examples (few-shot) | 2-5 varied examples inside <example> tags | Format and style get copied |
| XML tags | <document>, <instructions>, <output> | Parts of the prompt stay separate and clear |
| Role (system prompt) | "You are a senior SQL DBA" | Sets domain expertise and tone |
| Let it think (CoT) | Turn thinking on or ask for step-by-step in <thinking> | Accuracy improves on complex reasoning |
| Prompt chaining | Break a big task into a chain of small prompts | Each step can be debugged and improved |
| Output format control | Say what to do ("write in prose"), less of what not to do | Positive instructions are followed better |
| Structured output | Use a JSON schema (structured outputs) | Guaranteed parseable output |
4.2 What a good prompt looks like
<role>You are a senior C# code reviewer.</role>
<context>
This code belongs to a banking API. The team uses .NET 8.
Junior developers will read the review, so keep the language simple.
</context>
<code>
{{CODE_HERE}}
</code>
<instructions>
1. Find bugs and security issues (most serious first).
2. For each issue: line number, problem, fix code.
3. If there is no issue, say so clearly; do not invent issues.
</instructions>
<output_format>Markdown table: Severity | Line | Issue | Fix</output_format>4.3 Long context (large documents) tips
- Put long documents at the top of the prompt and the question / instructions at the end — this gives better quality.
- Wrap each document in <document>, with <source> and <document_content> inside.
- Ask it to first extract the relevant quotes, then answer based on them — this reduces hallucination.
4.4 Ways to reduce hallucination
- Give Claude explicit permission to say "I don't know".
- Restrict the answer to the provided document and ask for citations.
- Ask for a supporting quote for every claim; drop the claim if no quote is found.
- Provide fresh, grounded data through web search / RAG.
- Best-of-N: run the same prompt several times and flag inconsistent answers.
4.5 Prompting changes for newer models
| Old habit | What to do now |
|---|---|
| ALL CAPS, "CRITICAL: YOU MUST" | Use normal language; newer models follow instructions more literally and over-trigger |
| Assistant prefill (writing the last assistant turn yourself) | 400 error on newer models (4.6+ / 5.x). Use structured outputs or the system prompt |
| temperature / top_p tuning | These params were removed in the new API version; control with effort |
| "Think step by step" everywhere | Keep adaptive thinking on; the model decides how much to think |
| Very prescriptive step-by-step rules | Give goal + constraints + context; give capable models room |