goodharts-law — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited goodharts-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.
"When a measure becomes a target, it ceases to be a good measure." — Charles Goodhart, 1975 (popularized by Marilyn Strathern)
The moment you tell people they'll be evaluated by a number, they start optimizing for that number — often in ways that are disconnected from, or actively harmful to, the underlying goal the number was meant to represent.
This isn't because people are bad. It's because optimizing for a proxy is easier and more legible than optimizing for the underlying reality.
| What you measure | What gets gamed |
|---|---|
| Lines of code written | Verbose, redundant code |
| Bugs closed | Bugs closed without fixing, or marked as duplicates |
| Velocity (story points) | Points inflated per story |
| Test coverage % | Trivial tests that don't assert anything meaningful |
| PR count | Many tiny, low-value PRs |
| Support tickets resolved | Quick closes without real resolution |
| Time to first response | Auto-responses that count as "responses" |
A measurement is a proxy for the thing you actually care about. When you turn the proxy into the goal, you create pressure to optimize the proxy — and the path of least resistance is often to do that without actually improving the underlying thing.
A good engineering team and a mediocre one can produce the same velocity number. A resolved ticket doesn't mean a happy customer. The number gets decoupled from reality.
Use multiple metrics together, not any one metric in isolation. Gaming one metric is easy. Gaming five simultaneously, when they pull in different directions, is much harder. Pair velocity with defect rates. Pair ticket resolution with customer satisfaction.
Audit the proxy-to-reality relationship regularly. Ask: does this metric still represent what we want? Talk to people. Watch their behavior. A metric that's being gamed will show up as suspicious patterns.
Weight outcomes over outputs. Outputs (PRs merged, tickets closed) are easy to count. Outcomes (users retained, errors reduced, feature adoption) are harder to fake. Wherever possible, measure outcomes.
Make the goal transparent, not just the metric. If people understand why you're measuring something, they're less likely to optimize the measure at the expense of the goal. "We measure velocity to understand predictability, not to evaluate individual performance" changes how people relate to the number.
Don't use a metric for evaluation if it's also used for improvement. Measurement used purely for learning stays honest. Measurement tied to compensation or promotion gets gamed.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.