System Prompts
The single biggest lever in a production system prompt is replacing ambiguous instructions with explicit, categorical decision boundaries that tell Claude exactly what to flag and what to skip.
A system prompt sets the standing rules for how Claude behaves across every turn of a task. The most common production mistake is not length or tone — it is ambiguity. Instructions like *be conservative* or *only report high-confidence findings* read well to a human but give the model no actionable decision boundary. The fix is to specify concrete categories and triggers so that two invocations on similar inputs classify them the same way.
Vague language versus explicit criteria
Compare two versions of the same instruction. The weak version — *Review this code. Be conservative. Only report high-confidence findings.* — leaves the model to invent its own definition of *conservative*. The strong version names the categories: *Flag comments only when the claimed behaviour contradicts the actual code. Report bugs and security vulnerabilities. Skip minor style preferences and local conventions.* Every clause is a rule the model can apply without interpretation.
Subjective adjectives leave the model to invent its own boundary, so similar inputs get classified differently across runs.
Review this code. Be conservative.
Only report high-confidence findings.Named categories and triggers give one decision boundary the model applies without interpretation.
Flag only when a comment contradicts the code,
a change introduces a bug, or a change adds a
security vulnerability. Skip style preferences
and existing local conventions.Replace subjective adjectives (conservative, thorough, high-confidence) with categorical triggers that name exactly what to include and what to exclude. Decision boundaries, not vibes.
You are a code reviewer. Apply these rules exactly.
FLAG when:
- A comment's claimed behaviour contradicts the actual code.
- A change introduces a bug (wrong logic, off-by-one, null deref).
- A change introduces a security vulnerability (injection, auth bypass, secret leak).
SKIP:
- Style preferences (naming, spacing, import order).
- Local conventions already used elsewhere in the file.
For each finding, output: file, line, category, and a one-line justification
that cites the specific code that triggered the rule.Calibrate severity with code, not prose
Severity levels defined in prose (*Critical: issues causing system failures or data loss*) still leave the boundary to interpretation. Anchor each level to a concrete code pattern instead: unsanitised SQL string interpolation is *critical*; an inconsistent variable name is *minor*. Concrete exemplars remove the interpretive burden and produce consistent classification across runs.
Why confidence filtering fails
A tempting shortcut is to ask Claude for a confidence score and drop anything below a threshold. This does not fix false positives, because self-reported confidence is poorly calibrated — models are often certain about wrong findings and hesitant about right ones. Confidence scores are useful for routing (send low-confidence items to a human) but cannot replace explicit criteria for defining what counts as a valid finding. The hierarchy is explicit criteria first, confidence-based routing second.
Filtering by a self-reported confidence score drops correct findings and keeps confident wrong ones — miscalibration, not a validity rule.
if finding.confidence < 0.8:
drop(finding) # silently loses true positivesDefine validity with explicit criteria, then use confidence only to route uncertain items to a human.
if matches_criteria(finding):
report(finding)
if finding.confidence < 0.8:
route_to_human(finding)The false-positive trust problem
False positives in one category poison trust in all of them. If *documentation mismatch* findings are wrong 40% of the time, developers start ignoring even the *security* findings that run at 98% accuracy. The counterintuitive remedy: temporarily disable the noisy category while you rewrite its criteria, so the trustworthy categories keep their credibility, then reintroduce the fixed one.
When a category shows a high false-positive rate, the correct move is to disable and refine it with explicit criteria and code examples — not to raise a confidence threshold or keep all categories running while you tune.
| Weak instruction | Explicit replacement |
|---|---|
| Be conservative | Flag only X, Y, Z; skip everything else |
| Only high-confidence findings | Report findings matching these named categories |
| Critical = serious issues | Critical = unsanitised SQL input (with example) |
| Filter by confidence score | Route low-confidence items to human review |
How the exam will try to trick you
The distractors below look right under time pressure — learn the tell.
- The trap
Tighten the prompt with words like be conservative or only report high-confidence findings.
Correct answerGive explicit categorical criteria that name exactly what to flag and what to skip.
Why: The model has no actionable definition of *conservative*, so vague adjectives do not improve precision.
- The trap
Add a confidence threshold to the prompt to cut false positives.
Correct answerDefine validity with explicit criteria first, then use confidence only for routing uncertain items to a human.
Why: Self-reported confidence is poorly calibrated — it drops true positives and keeps confident wrong ones.
- The trap
Keep every review category running while you tune the noisy one.
Correct answerTemporarily disable the high false-positive category and refine its criteria and code examples before re-enabling it.
Why: A noisy category poisons trust in all categories; disabling it protects the credibility of the accurate ones.
Key takeaways
- Replace ambiguous adjectives with explicit categorical criteria that name what to flag and what to skip.
- Calibrate severity levels with concrete code examples, not prose descriptions.
- Self-reported confidence is poorly calibrated; use it for routing, never as the definition of a valid finding.
- High false positives in one category erode trust across all categories.
- To fix a noisy category, temporarily disable it and refine its criteria rather than tuning thresholds.
Frequently asked questions
What makes a Claude system prompt effective in production?+
Explicit, categorical decision boundaries. Instead of subjective language like 'be conservative,' the prompt names the exact conditions that trigger each action and anchors severity levels to concrete code examples, so classifications stay consistent across invocations.
Can I use confidence thresholds to reduce false positives?+
No — model self-reported confidence is not reliably calibrated, so thresholds can drop correct findings and keep wrong ones. Use confidence to route uncertain findings to human review, but define validity with explicit criteria, not scores.