hyrums-law — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited hyrums-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.
"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." — Hyrum Wright, 2012
If enough people use your API, every behavior — documented or not, intentional or not, even bugs — will be depended upon by someone. Your documented interface is not the real interface. The real interface is everything observable: response times, error message text, ordering of results, whitespace in JSON output, HTTP headers, memory usage patterns.
This has a humbling implication: as an API grows, your ability to change anything without breaking someone approaches zero.
When you're building for a small set of users, you can coordinate changes. When your API is used by thousands of developers, you can't know what they've built. Some of them will have:
Minimize observable surface area. The less you expose, the less gets depended on. Keep internals genuinely internal. Be deliberate about what is observable versus what is an implementation detail.
Version your APIs. Versioning is the escape hatch. When you need to change behavior, version the API and give users a migration path. /v1/ and /v2/ coexist; users migrate on their timeline.
Deprecate slowly and loudly. Give users long warning periods before removing or changing behavior. Emit deprecation warnings in responses. Document the change prominently. Provide migration guides.
Test your actual observable behavior, not just your documented interface. If you have a contract you want to preserve, write tests that encode it explicitly — including behaviors you consider "implementation details" that you don't want locked in.
Be careful about "fixing" bugs in stable APIs. A bug that has been in production long enough is effectively a feature. Evaluate whether fixing it is worth breaking users who depend on the buggy behavior. Sometimes the answer is yes; often it's "add a new endpoint that behaves correctly."
Document what is stable and what is not. Explicitly marking something as "internal," "unstable," or "do not depend on this" doesn't prevent all dependence — but it gives you standing to break it later without feeling you've betrayed your users.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.