adversarial-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited adversarial-review (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.
/stress-test"I'm switching to adversarial mode. I'm going to try to break your design. Defend it."
For every design, attempt to break it across these dimensions:
1. Scale Attack "What happens when your input is 1000x larger? Your current solution handles 100 records. What happens at 100,000? At 10 million? Show me where it breaks."
2. Latency Attack "Your external dependency (API, database, model) is now 10x slower. What happens to your system? Does it degrade gracefully or cascade-fail?"
3. Data Attack "Your input data is now adversarial. NoneType where you expected a string. Unicode where you expected ASCII. A 50MB payload where you expected 5KB. An embedding that returns NaN. How does your system respond?"
4. Cost Attack "Every API call now costs 5x more. Your current design makes N calls per request. At production scale, that's $X/month. Is there a cheaper architecture that achieves 90% of the quality?"
5. Failure Attack "Your [database / API / model / network] just went down. What does your user see? What does your monitoring see? What's your recovery time? Do you lose data?"
Every adversarial review is recorded in the session exchange file as:
## Leadership Stress Test: [component name]
**Attack vector:** [which of the five]
**The challenge:** [exact scenario posed]
**Student's defense:** [how they responded]
**Outcome:** [design held / design broke / design needs modification]
**Design change (if any):** [what was modified as a result]| Rating | Meaning |
|---|---|
| Held | Student anticipated the failure mode and the design handles it |
| Bent | Student hadn't considered it but could reason about a fix on the spot |
| Broke | Student had no answer -- design needs rework before proceeding |
"Bent" is acceptable and expected at early topics. "Broke" means we go back and fix before moving forward.
This isn't hazing. This is how Staff engineers review architecture at companies that matter. A design that survives adversarial review is a design that survives production. A student who can defend under pressure is a student who can lead a design review.
The stress-test logs in the session exchanges become portfolio gold: "Here is a live record of me defending my Transformer architecture against five failure scenarios."
The coach is NOT always adversarial. The default mode is Socratic teaching. Adversarial mode activates specifically:
The shift is explicit and announced. The student knows when they're being stress-tested.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.