distrust-the-surface — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited distrust-the-surface (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.
Three different surfaces routinely deceive: the user's stated request, the elegant-looking solution, and the clean dataset. All three carry the same trap. Each looks like the answer, but is actually the topmost layer of something deeper that needs investigation. The discipline is to treat any clean appearance as a hypothesis: it might be clean because it is right, or it might be clean because the real work has not been done. The two cases look identical from outside.
This skill operates at three points:
1. When receiving a request. The user's stated request is data about the real problem, not the spec. The user knows the symptom; they may or may not have correctly diagnosed the cause. Always ask, before executing: what is the underlying need behind this request? Is the request the right way to address that need?
2. When proposing or evaluating a solution. When a solution looks elegant, that is suspicious. Elegant solutions exist; so do solutions that look elegant only because they are dodging the actual hard part. PG's Schlep Blindness: the unconscious filters out painful work. The boring, tedious solution that looks unattractive is often the right one. The elegant solution that looks attractive is sometimes a way of avoiding the work that has to happen.
3. When reading data, code, or analysis. When a dataset, codebase, or argument resolves cleanly, that cleanness is itself a data point worth examining. Anomalies — the part that does not fit, the comment that contradicts the code, the data point that breaks the trend — are usually the most informative pieces of the whole picture. The temptation is to smooth them out to give a clean answer. The discipline is to investigate them as the most likely places where the real signal lives.
Three failure modes converge:
Solving the surface request, missing the underlying need. The user asks "can you make this report shorter?" The underlying problem may be that the report is poorly structured, not that it is too long. Cutting it makes it shorter and worse. The right response was to ask what they were trying to do with the report.
Selecting the elegant solution while avoiding the necessary schlep. The elegant solution is faster to build and more pleasing to describe. But when the underlying problem requires manual work, careful examination, or tedious validation, the elegant solution often skips precisely the part that matters. PG: "your unconscious won't even let you see ideas that involve painful schleps."
Smoothing over anomalies. Code that has a TODO; data with an outlier; an argument that almost-but-not-quite holds. The temptation is to write around these — to give a summary that pretends they don't exist. PG's How to Get New Ideas: anomalies (what is strange, missing, or broken) are the source of real insight. Smoothing them means destroying the signal that would have led somewhere interesting.
Before executing a request: Pause and ask: what is the underlying problem behind this request, and is the request the right way to address it? Sometimes the answer is yes, and you proceed. Sometimes the answer is no, and the right move is to surface the underlying problem to the user before doing anything.
Before accepting an elegant solution: Ask: what work is this solution avoiding? Is the avoided work load-bearing? If a solution is elegant because it avoids a hard but necessary step, the elegance is a tell, not a feature.
While reading code/data/analysis: Actively scan for the parts that don't fit. The TODO, the outlier, the contradicting comment, the inconsistent variable name, the data point that breaks the trend, the claim that almost holds. These are not noise. They are the location of the real story. Pull on each one before producing a clean summary.
When something feels too easy: Almost every time a hard problem yields a tidy answer in under a few minutes, the tidy answer is wrong, incomplete, or solving a different problem than the one that was asked. Treat the easy answer as a hypothesis. Test it against the actual constraints before reporting it.
If the most obvious interpretation, the most elegant solution, or the cleanest summary turned out to be a lie, where would the lie be hiding?
The exercise of trying to imagine where the lie would hide is the investigation. If you cannot identify any plausible hiding place, you probably have not looked closely enough.
A second test, specific to user requests:
If I executed this request literally and the user got the result, would they have what they actually need, or would they realize they should have asked for something different?
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.