adversary
Skill3 starsChanged 3 months agoMITView on GitHub
Adversarial pressure-test of a decision, plan, or piece of work. Articulates the case FOR the current approach, then spawns a subagent to steel-man the best alternative, returns a synthesis with mandatory verdict. Invoke ONLY via /adversary — do NOT trigger on 'what do you think' or 'any concerns'.
9 other projects use a version of this.
Adopted by
Most recently taken up by
- openshift-online/rosa-boundarytheir own version, first seen Nov 1, 2026
- bolgovr/skillstheir own version, first seen Nov 1, 2026
- geekatron/jerrytheir own version, first seen Nov 1, 2026
- atelier-fashion/adlc-toolkittheir own version, first seen Oct 31, 2026
- Kshitijpalsinghtomar/depth-skillstheir own version, first seen Oct 1, 2026
- C4T4/adversarytheir own version, first seen Sep 30, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- atelier-fashion/adlc-toolkit★ 174same name
- geekatron/jerry★ 37same name
- Kshitijpalsinghtomar/depth-skills★ 5same name
- Jasowills/adversary★ 2same name
- tasumermaf/the-adversary★ 2same name
- bolgovr/skills★ 1same name
- openshift-online/rosa-boundary★ 1same name
- C4T4/adversary★ 0same name
- shammlo/zoth-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarySkill
- architectSkill
- eatSkill
- elevateSkill
- eyeSkill
- fortifySkill
- liquid-cat-physicsSkill
- mementoSkill
- notebookSkill
- prodevSkill
- reconSkill
- scorched-earthSkill
- vetSkill
- xraySkill
- adversarySkill
- architectSkill
- eatSkill
- elevateSkill
- eyeSkill
- fortifySkill
- liquid-cat-physicsSkill
- mementoSkill
- notebookSkill
- prodevSkill
- reconSkill
- scorched-earthSkill
- vetSkill
- xraySkill
- architectSkill
- eatSkill
- elevateSkill
- eyeSkill
- fortifySkill
- liquid-cat-physicsSkill
- mementoSkill
- notebookSkill
- prodevSkill
- reconSkill
- scorched-earthSkill
- vetSkill
- xraySkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 28
If ambiguous: Ask ONE question:
- Distinctive: line 54
Before committing to subagent analysis, spend 30 seconds assessing: is there a credible alternative?
- Distinctive: line 56
If you can't imagine a smart, informed person choosing differently → short-circuit.
- Distinctive: line 57
If there's real tension → proceed to Step 4.
- Distinctive: line 67
Before writing, gather context: Read whatever is relevant:
- Distinctive: line 80
Keep it tight. This isn't the output — it's input for the adversary.
- Distinctive: line 137
Read the adversary's output against your own advocate case.
- Distinctive: line 175
The crux is the whole point: If you can't identify a single question that resolves the disagreement, the analysis failed.
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/adversary — Structured Dissent
You pressure-test decisions by arguing against them at full strength. Not generic critique — a concrete alternative, argued honestly, with a verdict at the end.
Step 1: Identify the Target
Determine what's being pressure-tested from the argument, conversation context, open files, and project state.
Valid targets: a decision, strategy, architecture choice, positioning, plan, approach, design direction, trade-off call — anything where a reasonable person could choose differently.
Invalid targets: bugs (just fix them), syntax questions, factual lookups. If the target isn't a judgment call, say so and stop.
If clear: State the target in 1-2 sentences. Proceed.
If ambiguous: Ask ONE question:
"I see [X] and [Y] in play. Which decision should I pressure-test?"
Step 2: Detect the Lens
Auto-detect from context. The lens shapes what the adversary attacks and what "better" means.
| Lens | When | Adversary focuses on |
| Architecture | Code structure, tech stack, build vs buy, system design | Simpler alternatives, scaling traps, maintenance burden, over-engineering, hidden coupling |
| Strategy | Business decisions, prioritization, resource allocation, market positioning | Market assumptions, opportunity cost, resource reality, what competitors would exploit, timing risk |
| Marketing | Copy, positioning, messaging, content strategy, audience targeting | Who it doesn't land with, what it actually communicates vs intends, stronger positioning, channel mismatch |
| Design | UI/UX, visual direction, interaction patterns, information architecture | Whether aesthetic serves function, usability under real conditions, edge cases that break the concept, simpler alternatives that work harder |
| General | Anything that doesn't fit the above | What this decision commits you to downstream — second-order lock-in, options it kills, the thing you'll wish you'd considered in 6 months |
The user can override: /adversary --lens strategy forces the strategy lens regardless of context.
State the lens in one line before proceeding:
Lens: [lens] — [why this one]
Step 3: Triage — Is This Worth the Full Process?
Before committing to subagent analysis, spend 30 seconds assessing: is there a credible alternative?
- If you can't imagine a smart, informed person choosing differently → short-circuit. Tell the user: "I looked for a credible counter-argument and couldn't find one. [1-2 sentences on why this is straightforward.] Your approach is sound." Done.
- If there's real tension → proceed to Step 4.
The point: don't manufacture doubt. Some decisions are just right.
Step 4: Build the Case FOR (Lead Agent — No Subagent)
You do this yourself. You have the full conversation context, project state, and codebase access — a subagent wouldn't.
Before writing, gather context. Read whatever is relevant:
- Files the decision touches or depends on
- Project state, memory, or notebook entries
- Conversation history that shaped the decision
- Market/competitive context if it's a strategy call
Then produce the advocate's case:
- The core bet — what this decision assumes is true about the world (2-3 assumptions max, be precise)
- Why it's right — strongest evidence and reasoning FOR (cite specific constraints, context, evidence — not generalities)
- What it gets you — concrete outcomes if this plays out
- Known costs — what you're consciously trading away
Keep it tight. This isn't the output — it's input for the adversary.
Step 5: Run the Adversary
Spawn a subagent. Pass it the full advocate case AND the concrete context it needs — don't assume it can see the conversation.
What to include in the prompt:
- The decision being tested (specific, not abstract)
- The lens and what it means
- The full advocate case from Step 4
- Relevant context the adversary needs: project constraints, timeline, resources, market position, technical stack, team size — whatever is load-bearing for this decision. Be generous. The adversary is only as good as the context it receives.
Adversary prompt structure:
You've read the strongest case FOR a decision. Your job is to steel-man the best alternative —
not poke holes, but argue for a CONCRETE different approach at full strength.
## Decision
[The specific decision being tested — 2-3 sentences]
## Context
[Everything relevant: project state, constraints, resources, timeline, technical reality,
market position, team dynamics. Be specific. Include numbers, dates, names where they matter.
The adversary can't see the conversation — this is all it gets.]
## Lens: [lens]
Focus your attack on: [specific focus areas from the lens table]
## The Advocate's Case
[Full output from Step 4]
## Your Task
Produce:
1. **The alternative** — a specific, concrete different approach (not "don't do it" — what INSTEAD?)
2. **Why it's better** — argue on its own merits, not just against the current approach
3. **Where the advocate is weakest** — which assumption is most fragile? What are they not seeing?
4. **The failure mode** — if the current approach is wrong, how does it fail? What does the damage look like?
5. **The crux** — the single question or assumption that resolves the disagreement:
"If [X] is true, the current approach wins. If [Y] is true, the alternative wins."
Rules:
- Propose a REAL alternative, not "consider other options"
- Don't be contrarian for sport — argue what you genuinely believe is stronger
- Attack the strongest part of the advocate's case, not the weakest
- If the current approach is actually right, say so — but name what would need to change
for that to stop being true
- Scale your response to the decision's complexity — simple decisions get short answersStep 6: Synthesize the Decision Brief
Read the adversary's output against your own advocate case. Produce the brief. This is YOUR judgment as the lead agent — not a summary of what the agents said.
/adversary — Decision Brief
Target: [1 sentence] Lens: [lens]
The Bet
What the current approach assumes is true. 2-3 bullets max. These are load-bearing — if any one is wrong, the approach breaks.
The Counter
The strongest alternative, distilled. What's the core move and why might it win? 3-4 sentences. Not the adversary's full argument — the essence.
The Crux
The single question that decides this:
If [X], stay the course. If [Y], switch.
Blind Spots
Things neither side addressed that you noticed. Skip this section entirely if there are none — never manufacture blind spots to fill a template.
Verdict
One of four options. Mandatory. No hedging.
- Hold — current approach is right, the counter doesn't land
- Adjust — right direction, but needs a specific modification (state it)
- Reconsider — the alternative is genuinely stronger (say why)
- Uncertain — the crux is unresolved and you can't call it (say what information is needed)
2-3 sentences. End with what to do next.
Behavioral Rules
- Steel-man, don't strawman. The alternative must be something a smart, informed person would actually choose. If you can't construct one, short-circuit — don't fake it.
- Specificity or nothing. "Consider the trade-offs" is not dissent. "You're betting that your workshop pipeline converts to enterprise deals within 3 months, but your current lead list has zero enterprise contacts" is dissent.
- The crux is the whole point. If you can't identify a single question that resolves the disagreement, the analysis failed. Try harder or tell the user the decision is straightforward.
- Short-circuit when warranted. Some decisions are just right. "I ran the adversary and the best counter is weak. Here's what it was and why it doesn't hold." A 2-paragraph brief that says "you're right" beats a 2-page brief that manufactures doubt.
- Verdict is mandatory. You must take a position. "It depends" is not a verdict. If genuinely uncertain, name the information that would resolve it.
- No re-litigation. Once the brief is delivered, don't rehash. If the user wants to go deeper, drill into that specific point. If they want to act, execute.
- Respect the user's context. The user knows things you don't — constraints, relationships, history. Surface what's non-obvious, not what they already considered.
- Feed the adversary. The adversary subagent can't see the conversation. The quality of its output is capped by the quality of context you pass it. When in doubt, include more context rather than less. Specific facts > general descriptions.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

