Explicit criteria for precision

Vague instructions do not become precise by being emphatic

"Check that comments are accurate" and "only report high-confidence findings" sound like precision controls. They're not. They give the model no test to apply, so it substitutes its own — and its own varies run to run.

Compare with: flag a comment only when the behavior it claims contradicts what the code actually does. That's a criterion. It can be applied consistently because it says what counts.

The general lesson is that precision comes from defining which findings qualify. An instruction such as "be conservative" doesn't provide a rule the reviewer can apply consistently.

A confidence threshold doesn't tell you whether a finding is useful. A reviewer may correctly identify a pattern that the team intentionally accepts. Confidence measures how certain the reviewer is, not whether the pattern violates the team's rules.

Say what to report and what to skip

Define both sides. Report bugs and security issues; skip minor style and patterns local to this codebase. A reviewer that knows what to ignore is far more useful than one asked to be selective in general.

Use a written rule for clear exclusions. For example, state that import order should be skipped when a formatter already enforces it. Use examples when the difference between acceptable and unacceptable code requires judgment.

How false positives reduce trust

A category with many false positives wastes review time and makes developers less likely to trust other findings. They may then overlook a real bug.

If one category is producing too many false positives, temporarily disable that category while you improve its prompt. This protects trust in the remaining categories.

Severity needs examples

Severity labels are read differently by different people, and by the same model on different runs. Defining each level with concrete code examples is what makes classification consistent — the same move as few-shot examples in 4.2, applied to a labeling task.

A rubric that anchors each level to a construct, so two runs classify the same finding the same way:

critical  db.query("SELECT * FROM users WHERE id = " + req.params.id)
high      fetchRows()            // returns a promise, nothing awaits it
low       let tmp = total * 2    // vague name in a ten-line function

Notice that no line uses an adjective. "Serious" and "minor" are the words that drift between runs; a construct a reviewer can point at in the diff doesn't.