Prompt Engineering for Claude: Explicit Criteria and Few-Shot Examples
Two prompt-engineering skills dominate the exam: writing explicit criteria instead of vague instructions, and using few-shot examples when instructions alone give inconsistent results (Task Statements 4.1 and 4.2).
⚙️ Explicit criteria beat vague instructions
| Vague (doesn’t improve precision) | Explicit (does) |
|---|---|
| “Check that comments are accurate.” | “Flag a comment only when the behaviour it describes contradicts what the code actually does.” |
| “Be conservative.” | “Report: logic bugs, security vulnerabilities, data loss. Skip: formatting, naming, patterns consistent with local conventions.” |
| “Only report high-confidence findings.” | A severity rubric with a concrete code example for each level. |
🤝 Protect developer trust
A category with many false positives makes developers ignore all findings, including accurate security ones. Temporarily disable the noisy category while you improve its prompt, then re-enable it.
🧪 Few-shot examples
- Few-shot examples are the most effective way to get consistently formatted, actionable output when detailed instructions still vary.
- Use 2–4 targeted examples of ambiguous cases, and show the reasoning for why one option beat the plausible alternatives.
- Good examples help Claude generalise to new cases rather than just pattern-match.
- Show the exact output format (location, issue, severity, suggested fix).
- Contrast acceptable patterns with genuine issues to cut false positives.
- For extraction, show documents with different structures (inline citations vs bibliography, tables vs narrative) to reduce empty fields and hallucinations.
<example>
Code: user = repo.find(id) # reflection-based DI injects repo
Finding: none
Reasoning: repo looks unused but is injected via reflection — acceptable pattern.
</example>
<example>
Code: total = price * qty; return round(total)
Finding: {location: "cart.py:42", issue: "rounds currency with float", severity: "high",
fix: "use Decimal and quantize to 2 places"}
Reasoning: float rounding loses cents in real orders.
</example>🧪 Exam-Style Practice Questions
Try these before opening the answers. They use the same scenario style as the real exam.
Question 1. A review prompt says "check that comments are accurate" and flags many harmless comments. What's the best rewrite?
- A. "Only report high-confidence issues."
- B. "Ignore comments."
- C. "Be conservative."
- D. "Flag a comment only when the behaviour it describes contradicts what the code actually does."
Show answer
Answer: D. Explicit categorical criteria improve precision. C and A are vague and proven ineffective. B throws away the category entirely.
Question 2. Detailed instructions still give inconsistently formatted findings. What's the most effective technique?
- A. Lower `max_tokens`
- B. A larger model
- C. More instructions
- D. Few-shot examples showing the exact format (location, issue, severity, fix)
Show answer
Answer: D. Examples beat added prose for format consistency. C, B and A don't target the cause.
Question 3. The "naming" findings category has an 80% dismissal rate, and developers have started ignoring *all* findings. What's the best immediate action?
- A. Raise the severity of everything
- B. Temporarily disable the naming category while you improve its prompt, to restore trust
- C. Switch models
- D. Keep everything and add a disclaimer
Show answer
Answer: B. Noisy categories erode trust in the accurate ones. D doesn't fix the trust problem. C isn't targeted. A makes it worse.
📝 Assignment
Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.
- Task 1: Rewrite a vague review instruction from your team as explicit report and skip criteria.
✅ Done when: Your rewrite lists what to report and what to skip, with no words such as 'be careful' or 'high confidence'. - Task 2: Write a severity rubric with one code example per level.
✅ Done when: Each severity level has one short code example that a teammate would classify the same way. - Stretch: add three few-shot examples to a prompt and measure the change in format consistency over ten runs.
✅ Done when: You recorded format consistency for ten runs before and after adding the examples.
❓ Frequently Asked Questions
🤔 Does 'only report high-confidence findings' reduce false positives?
No. The exam guide notes that vague confidence instructions don't improve precision; explicit categorical criteria do.
🤔 How many few-shot examples should I use?
Two to four targeted examples of ambiguous cases, with the reasoning for each choice.
🤔 Why disable a noisy review category?
High false-positive categories make developers ignore all findings, including accurate ones.
🤔 Do few-shot examples help extraction?
Yes. Examples that cover different document layouts reduce empty and invented fields.
🏁 Summary
- Replace vague instructions with categorical report/skip criteria.
- Disable noisy categories temporarily to restore trust.
- 2–4 targeted few-shot examples with reasoning give consistency and generalisation.
Next, continue with Claude Structured Output with tool_use and JSON Schema.
Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.