state-the-noise-floorlisted
Install: claude install-skill serhiy-bzhezytskyy/contrib-receipts
# State the noise floor, not just the count
## Purpose
A number is the most persuasive thing you can hand a maintainer and the easiest thing
to get wrong. "14 of 19 operations regressed" and "917 records are stale" both read as
findings, and both can be exactly what you would see if nothing at all were wrong —
because measurements repeat differently, and because base rates produce coincidences
at scale.
The fix is one question asked *before* publishing: **what would this same number be if
there were no effect?** Answer it by measuring, not by estimating. Then quote the ratio,
not the raw count. A maintainer who sees `917 vs 633 expected by chance` can act on it;
a maintainer who sees `917` and later discovers the floor has learned that your numbers
need checking.
This is cheap, it is often a single extra loop or a `shuffle()`, and it is the
difference between a claim that survives review and one that gets quietly discounted.
## When to use
- You are about to write a number into an issue, a PR description, a benchmark report
or a mailing-list post — a count, a percentage, a rate, or an A-vs-B delta.
- You ran a performance comparison, in any form. **One run per side is a demo, not a
result.**
- You mined a corpus (issues, commits, logs) and are about to report "N items match".
- A tool you are using reports a variance statistic (RSD, stddev, confidence interval)
and you were about to read only the mean.
## When NOT to use
- The property is **deterministic and uni