finding-triage

finding-triage — the significance gate: TRUE and MATTERS

The spine, one question per candidate:

Would the author do something differently because I raised this?

A finding must clear two bars, and clearing one is not a partial pass:

1. TRUE — the code really behaves the way the finding says, and you can name the line where the mechanism lives.
2. MATTERS — acting on it changes this change, for a consumer that exists.

Almost all review noise is findings that clear only the first bar. They are accurate, they are checkable, and they are worthless: the reviewer spends credibility, the author spends a reply, and the code ends where it started. A producer of candidates — an adversarial agent, a grep pass, your own second read — is supposed to over-generate. This skill is the gate that stands between over-generation and a human's attention.

This skill does not generate findings. It consumes a list someone else produced and returns a disposition per item. It does not post to GitHub (that is pr-review / pr-suggestion), it does not edit code (that is the implementing skill), and it never opens a new investigation front — a candidate nobody proposed is out of scope, however tempting.

Bar 1 — TRUE

A finding is TRUE when you have read the current code and can state the mechanism at a named file:line. Not the smell, the mechanism: "parse() at handler.go:88 runs before the signature check at :104", not "validation ordering looks suspicious here."

Three things that masquerade as TRUE and are not:

• A pattern match. The shape resembles a known bug family. That is a reason to go look, not a finding. If the lookup did not happen, the candidate is unverified — say so, do not launder it into a claim.
• A summary. The PR description, a commit message, or another agent's confident paragraph is what is claimed. The file at HEAD is what is true. Read the artifact.
• A stale read. The finding was true at the commit the producer read. Check the current code before carrying it forward (see Already Addressed).