Severity Criteria with Examples
Anchor each severity level with a code example.
Why Severity Needs Criteria
When you ask Claude to review code, the weakest instruction you can give is a vague one: be more precise or only flag important issues. The model has no shared definition of "important", so its bar drifts from file to file.
The exam principle is blunt: explicit criteria beat vague adjectives. A severity scale (Critical / High / Medium / Low) is only useful if each level has a written rule the model can apply consistently — and the most reliable way to pin down a rule is to anchor it with a concrete code example.
This lesson builds a severity rubric for a CI/CD review agent, one level at a time, each level tied to an example.
The Failure Mode: Adjectives Without Anchors
Here is the kind of prompt that looks fine but performs badly. It names severity levels but never defines them, so the model guesses — and guesses differently each run.
The result is exactly the anti-pattern the exam warns about: noisy reviews where a missing null-check and a misspelled comment both get tagged "High". Reviewers stop trusting the labels.
system = (
"You are a code reviewer. "
"Rate each issue as Critical, High, Medium, or Low. "
"Be precise and only report important problems."
)
# Problem: 'important', 'precise', and the four levels are
# never defined. The bar is whatever the model infers today.All lessons in this course
- Explicit Criteria over Vague Instructions
- Categorical Examples
- Severity Criteria with Examples
- Reducing False Positives