test-like-you-mean-it — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited test-like-you-mean-it (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
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.
Agents write tests the way a student grades their own exam. They built the code, they want the code to work, so they write tests that confirm the happy path and assert whatever the code currently returns. The suite goes green, everyone relaxes — and nothing was actually verified. A test written to pass is worse than no test: it's a green light bolted over a blind corner.
The tell: tests that mirror the implementation ("returns X when given Y" where X was copied from the function's output), no test that could conceivably fail, no edge regimes, no invariants. Smoke tests presented as verification.
This skill replaces that with an adversarial wave: after the build, you switch sides. You are no longer the author defending the code — you are the reviewer trying to break it. Finding a real defect is the expected outcome, not an embarrassment.
Don't use when: the change is trivial plumbing with no behavior (a rename, a re-export), or you're in a genuine throwaway spike. Don't use it as a reason to write 100 shallow tests — ten tests that could fail beat a hundred that can't.
Before writing a single test, write down (briefly) how this code could be wrong in ways the existing tests wouldn't catch. You're drafting an attack plan, not a checklist of what it does. If you can't name a way it could be wrong, you don't understand it yet — go read it again.
The weakest test asserts the function's current output. The strongest asserts something that must be true independent of the implementation:
Happy-path inputs exercise the code; boundary inputs verify it. Zero, negative, empty, one, max, NaN-adjacent, timezone edges, unicode, concurrent access, the degenerate config where a denominator goes to zero. Pick the regimes that are plausible in production, not just exotic.
A failing adversarial test is the skill working. The order of suspicion: (1) the code is wrong, (2) your test's expectation is wrong, (3) the spec is ambiguous. Only change the test when you can articulate why reality disagrees with it — never to make the run green. If you weaken an assertion or delete a check, say so out loud in the report and justify it; silently loosening a test is the exact failure mode this skill exists to kill.
"47 tests, all passing" says nothing. Report what was attacked and what was found: which invariants were checked, which regimes probed, what broke, what was fixed, and what residual risk remains untested (and why).
Adversarial test wave: <component>
Attack plan: <the 3-6 ways this could plausibly be wrong>
Invariants tested: <list>
Regimes probed: <list>
Findings: <N real defects — each: what, root cause, fix> ← finding 0 on first wave is suspicious
Expectations changed: <any test whose assertion was altered, with justification>
Not tested: <what remains unverified and why>| Anti-Pattern | Why it defeats the skill |
|---|---|
| The mirror test | asserting whatever the implementation returns. That tests nothing but determinism. |
| Volume theater | 80 generated permutations of the same shallow assertion, presented as rigor. |
| Quiet loosening | widening a tolerance, deleting an assert, or skipping a case to get green, without flagging it. |
| "First wave found nothing, ship it" | a clean first adversarial pass usually means the attack plan was soft. Sharpen it once before believing it. |
You wrote the code as its advocate. Now prosecute it. A test suite is only worth what it could have caught — if no test in the wave could have failed, you didn't test, you decorated.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.