finding-falsificationlisted

# Finding Falsification ## What this is, and when to invoke it A reported finding is a claim. This skill makes every claim survive an attempt to refute it *by its own author* before it reaches the report. The battery runs per finding; the disposition rules make rejected work visible instead of silently discarded — a reader who cannot see what was rejected cannot calibrate trust in what was accepted. Invoke when authoring or reviewing a code-review reporting agent, and at report time inside the wired agents (security-auditor, code-quality-auditor, documentation-auditor, challenger) before findings are returned. ## The refutation battery (MUST, per finding) 1. **Toolchain check.** Is this a hand-derived finding duplicating what a linter/type-checker/formatter that ran in this session already reports? Don't duplicate the toolchain — duplicated findings train readers to skim. Surfacing the toolchain's own results where the agent's contract mandates it (a Linter Results section, a SAST report) is not duplication; check 1 targets hand-derived duplicates only. 2. **Backing check** *(pattern-claim findings only)*. A finding claiming a convention/standard/pattern violation must cite a concrete standard (file + section) OR an established code pattern, operationalized as **≥3 occurrences outside the diff (grep)** — "established" without a count is vibes. A defect demonstrable on its own terms (an exploit scenario, a crash, incorrect output) is its own backing; check 2 does not appl