linuss-law — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited linuss-law (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
"Given enough eyeballs, all bugs are shallow." — Attributed to Linus Torvalds; popularized by Eric Raymond in The Cathedral and the Bazaar, 1999
When enough people examine a codebase, bugs that might seem deeply hidden to any individual reviewer will be found. What's opaque to one person is obvious to another. Different reviewers bring different mental models, experiences, and areas of focus.
This is the argument for both code review and open source development as quality mechanisms.
Cognitive diversity. Different reviewers think differently. One person might miss an off-by-one error; another will spot it immediately. One reviewer notices the security implication that the author never considered.
Assumption blindness. Authors are blind to their own assumptions. You can't see what you took for granted. A reviewer who doesn't share those assumptions sees the gap.
Familiarity blindness. After staring at code, you read what you meant to write, not what you wrote. Fresh eyes catch typos in variable names, wrong constants, and logic inversions that authors routinely miss.
Specialization. A security engineer reviewing code finds different bugs than a performance engineer or a domain expert. Broader review coverage is richer review.
Make code review a non-negotiable practice. The research on code review is clear: it is one of the highest-ROI quality practices in software engineering. Even one additional reviewer catches a significant fraction of defects before they reach production.
Vary your reviewers. Don't always have the same person review the same person's code. Cross-domain reviews — someone less familiar with the code — catch different bugs than deep-expert reviews.
Make it easy to review. Small PRs, clear descriptions, linked context. Long PRs get shallow reviews. The review process should reduce friction for reviewers, not just for authors.
Use open source for security-critical components. Closed-source security components can't be audited externally. Open source components under wide use benefit from thousands of eyeballs, including security researchers actively looking for problems. This is why open source cryptographic libraries are generally trusted more than proprietary ones.
Bake in review time. Code review has a time cost, but the cost of not doing it — in bugs shipped, security incidents, maintenance debt — is higher. Treat review time as part of the development process, not as optional overhead.
Linus's Law is not unconditional. More eyeballs help, but:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.