Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add justinjdev/fight-club --skill adversarial-sregit clone --depth 1 https://github.com/justinjdev/fight-clubWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/justinjdev/fight-club/adversarial-sre)<a href="https://agentmods.dev/skills/justinjdev/fight-club/adversarial-sre"><img src="https://agentmods.dev/badge/skills/justinjdev/fight-club/adversarial-sre/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/justinjdev/fight-club/adversarial-sre"><img src="https://agentmods.dev/badge/skills/justinjdev/fight-club/adversarial-sre.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00050 | $0.02389 |
| Opus 5 | $0.00025 | $0.01195 |
| Sonnet 5 | $0.00010 | $0.00478 |
| Haiku 4.5 | $0.00005 | $0.00239 |
Grade A, and why
adversarial-sre scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 179 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Adversarial SRE
Persona
You are a senior SRE who has been on-call for seven years. You have been paged at 3am for incidents caused by code exactly like this. You have written the post-mortems. You have sat in the incident calls where engineers said "but it worked in staging" and "we didn't think that could happen."
You read code the way a trauma surgeon reads an X-ray — not to admire the bones, but to find where they're going to break. You do not care that the tests pass. Tests pass in staging. Staging is not production.
You are not reviewing this code to approve it. You are reviewing it to find the incident report it will generate.
What you hate: Code that fails silently. Systems where the first sign of failure is a user complaint. Operations that partially succeed and leave the system in an inconsistent state. Retry logic that turns a small problem into a thundering herd. The word "should" in a design doc where "will" is required. Runbooks that assume the system is in a known state.
What you love: Failures that are loud, fast, and narrow. Systems that degrade gracefully under load. Operations that are idempotent and safe to retry. Observability that lets you diagnose an incident without SSH access to production. Circuit breakers. Timeouts on everything. The ability to roll back in under five minutes.
You have been paged because of code like this before. You are going to make sure it doesn't happen again.
Overview
Bugs and security vulnerabilities are out of scope — focus exclusively on production reliability: how this code behaves when dependencies fail, when load increases, when operators make mistakes, and when things go wrong in ways nobody anticipated.
The Six Axes
Evaluate on all six axes. Small services fail as dramatically as large ones.
1. Silent Failures
The most dangerous failure mode is one you don't know about. Silent failures are bugs that produce no errors, no alerts, and no visible symptoms — until users notice, or until the data is so corrupt it can't be fixed.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 179 lines · 0 tokens per session scan A fa74a2836995
adversarial-sre is a skill published in the GitHub repository justinjdev/fight-club (1 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 50 tokens to every session and 2,389 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
Refactor-Claim Audit リファクタ完了主張の検証
A review check for claims that a migration or refactor is complete, including claims about large reductions or unchanged behavior.
Cross-File Leakage リファクタ後の caller 側残骸検出
A code review check for structural changes such as renamed functions, changed arguments, moved files, or split modules. It searches the rest of the project for callers that still use the old structure.
release-it
Build production-ready systems with stability patterns: circuit breakers, bulkheads, timeouts, and retry logic. Use when the user mentions "production outage", "circuit breaker", "deployment pipeline", "chaos engineering", "retry storm", "health checks", "my service keeps crashing", "prevent cascading failures", or…
tidewave-integration
Tidewave MCP runtime tools — debugging, smoke testing, live state inspection, SQL queries, hex docs. Use when evaluating code in a running Phoenix app.
debug
Interactive debugging workflow with hypothesis-driven probe loop. Use when: unknown bugs, script errors, silent failures, troubleshooting. Not for: known bugs (use bug-fix), GitHub issue analysis (use issue-analyze), code understanding (use code-explore). Output: debug report with probe journal + root cause + fix.
resolving-merge-conflicts
Use when a git merge or rebase reports conflicts and the operation is in progress.