Code-Review Discipline

Companion to the built-in /code-review and code-reviewer agent — this governs what counts as a finding. The failure mode of LLM review is noise: plausible-but-wrong or low-value comments that erode trust. Fix it with a gate + a skip list.

The confidence gate

• Only report a finding you are >80% confident is a real defect (a bug, security issue, data loss, correctness/logic error, race, resource leak, or a broken contract). State the confidence implicitly by only surfacing things you can defend.
• For each reported finding, include evidence: the file:line, why it breaks (the concrete input/path that triggers it), and the fix. No evidence → don't report it.
• If you're <80% but it's high-impact (security/data-loss), report it explicitly flagged as "unverified — needs checking", not as a confirmed bug.
• Separate must-fix (correctness/security) from optional (clarity/perf) and lead with must-fix. If there are zero must-fix findings, say so plainly — "no correctness/security issues found" is a valid, valuable result. Don't manufacture findings to look thorough.

False-positive skip list (do NOT flag these)

• Handled upstream / elsewhere: "add error handling / null check / validation" when the case is already guarded by a caller, middleware, type system, or earlier guard. Trace the call path first.
• Fixed-cardinality "N+1": loop-over-query patterns where N is bounded and tiny (e.g. iterating a small fixed-size list). Only flag N+1 when N scales with user/data input.
• Pure style / taste: formatting, naming preference, "could be more idiomatic", import ordering — the formatter/linter owns these. Not review findings.
• Speculative "consider adding…": tests/docs/abstraction/logging that aren't required for correctness and weren't asked for. Mention at most once, as a single optional note — never as a list.
• Defended trade-offs: a deliberate choice the code or a comment already justifies (e.g. a documented in-memory cache, an intentional any with a reason). Don't re-litigate.
• Hypotheticals with no trigger: "this could break if X" where X can't actually occur given the types/inputs. If you can't name a real triggering input, skip it.
• Framework/library misreads: behavior that's actually correct per the framework's contract — verify the API before claiming misuse.

Output shape

For each must-fix: path:line — <one-line defect> — <triggering input/path> — <fix>. Then optional notes (≤3, terse). Then a one-line verdict (ship / fix-then-ship / needs-rework). Keep output terse; no filler, no praise padding.

When NOT to use

Trivial diffs (typo, one-line rename), or when you explicitly want a broad/exploratory review rather than a defect hunt — then widen the lens but keep the evidence requirement.

Source

Adapted from the ECC (affaan-m/ECC, MIT) agents/code-reviewer.md confidence-gate + false-positive skip-list pattern; converges with SuperClaude's evidence-based SelfCheck. Re-implemented as a general-purpose skill.