red-team

Apply adversarial analysis to stress-test $ARGUMENTS. The goal is to find every weakness, not to be balanced.

When to use red-team vs council: Red-team is purely adversarial — attack the idea to find breaking points. /council is collaborative-adversarial — experts debate to find the best path forward. Use red-team when you need to validate robustness of a decision already made; use council when you need to choose between options.

Step 1: Decompose into atomic claims (mandatory)

Break the argument into independently testable claims:

### Claim inventory

| # | Claim | Type | Confidence |
|---|---|---|---|
| 1 | [specific claim] | Stated | [how confident is the author?] |
| 2 | [implied claim] | Implied | [inferred from context] |
| 3 | [required but unstated] | Required | [necessary for argument to hold] |

Claim types:

• Stated: Explicitly claimed in the argument
• Implied: Assumed but not stated — often the weakest points
• Required: Necessary for the argument to hold but not mentioned — often invisible

A plan with 5 sections typically decomposes into 15–25 atomic claims. If you find fewer than 10, you haven't decomposed far enough.

Output: Complete claim inventory with types and confidence levels.

Step 2: Steelman — build the strongest version (mandatory)

Before attacking, construct the strongest possible version of the argument. This ensures the red team attacks the best version, not a strawman.

### Steelman

The strongest case for this argument:

1. [Strongest supporting point — with evidence]
2. [Second strongest point]
3. [Third point]
...up to 8 key points

**Best available evidence:** [what data or precedent supports this]
**Strongest framing:** [how would the most skilled advocate present this?]

Rules for steelmanning:

• Fix obvious weaknesses before attacking — find the version the author would write with unlimited time
• Add the best supporting evidence, even if the author didn't include it
• Frame it in its most compelling form

Output: Steelmanned version with up to 8 key points.

Step 3: Attack every claim (mandatory)

For each claim from Step 1, apply these attack vectors:

### Attack: [Claim #N] — "[claim text]"

**Disproof test:** What evidence would disprove this? [specific evidence]
**Failure conditions:** Under what conditions does this fail? [scenarios]
**Weakest link:** What's the weakest step in the reasoning? [specific step]
**Unverified assumption:** What's assumed but not tested? [assumption]
**Strongest opposition:** Who would disagree most, and what's their best argument? [argument]

After attacking all claims, classify findings:

### Findings by severity

**Critical weaknesses** (would cause failure):
| # | Claim attacked | Weakness | Evidence | Impact |
|---|---|---|---|---|
| 1 | [claim #] | [weakness] | [why this breaks the argument] | [consequence] |

**Significant risks** (could cause failure under conditions):
| # | Claim attacked | Risk | Trigger conditions | Likelihood |
|---|---|---|---|---|
| 1 | [claim #] | [risk] | [when this becomes a problem] | High/Medium/Low |

**Unverified assumptions** (unknown whether true):
| # | Claim attacked | Assumption | How to verify | Cost of being wrong |
|---|---|---|---|---|
| 1 | [claim #] | [assumption] | [experiment or data needed] | [impact] |

Output: Classified attack findings with evidence.

Step 4: Verdict and recommendations (mandatory)

### Verdict

**Overall robustness:** [Robust / Conditionally sound / Fragile / Fatally flawed]

**Confidence in verdict:** [High / Medium / Low] — because [reasoning]

### Recommendations

**Must address before proceeding:**
1. [Critical weakness] — suggested fix: [approach]

**Should address if possible:**
1. [Significant risk] — mitigation: [approach]

**Verify when possible:**
1. [Unverified assumption] — how to test: [method]

Output: Overall verdict with prioritised recommendations.

Rules

• Attack the steelman, not the strawman. If you're attacking an obviously weak version, you're wasting time. Build the strongest version first (Step 2), then attack that.
• Specificity is mandatory. "This might not work" is not a finding. "Claim #3 assumes constant network latency, but spikes above 500ms would cause cascading timeouts in the sync path" is a finding.
• Implied claims are the richest target. What the author didn't say is often more vulnerable than what they did. Focus on Required and Implied claims.
• Severity matters more than count. One critical weakness outweighs ten minor risks. Don't pad findings with trivia to appear thorough.
• Never soften the verdict. If the argument is fatally flawed, say so. The purpose of red-teaming is to find truth, not to be diplomatic.
• The goal is improvement, not destruction. Every weakness identified should come with a direction for fixing it.

Output Format

## Red Team: [subject]

### Claim Inventory
[Decomposed claims from Step 1]

### Steelman
[Strongest version from Step 2]

### Attack Findings
[Classified findings from Step 3]

### Verdict
[Overall assessment from Step 4]

### Recommendations
[Prioritised fixes from Step 4]

Related Skills

• /council — for collaborative debate when choosing between options. Red-team validates; council decides.
• /first-principles — when the red-team reveals that the argument's foundations need re-examination.