# Adversarial Thinking

> Apply systematic adversarial thinking patterns including devil's advocate, assumption busting, red teaming, and white hat security approaches

- Skill: `wojons/adversarial-thinking` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add wojons/adversarial-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wojons/adversarial-thinking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: wojons (https://skillmd.com/u/wojons)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/wojons/adversarial-thinking

---


# Adversarial Thinking

Apply systematic adversarial thinking patterns to challenge assumptions, identify weaknesses, and improve decision quality through multiple complementary adversarial perspectives.

## When to use me

Use this skill when:
- Making high-stakes decisions with significant consequences
- Designing systems that must withstand real-world challenges
- Preparing for security reviews, audits, or compliance checks
- Building resilience against failures, attacks, or market changes
- Preventing groupthink and confirmation bias in teams
- Stress-testing ideas, designs, or implementations
- Improving system security and robustness
- Developing critical thinking skills across the organization
- Preparing for competitive environments or adversarial conditions

## Adversarial Thinking Framework

Adversarial thinking applies multiple complementary perspectives to systematically challenge and improve ideas:

### 1. **Devil's Advocate** (@skills/devils-advocate)
- **Purpose**: Challenge ideas through logical counterarguments and alternative perspectives
- **Focus**: Logical reasoning, argument quality, alternative explanations
- **When to use**: Decision-making, proposal evaluation, preventing groupthink
- **Output**: Counterarguments, weaknesses, alternative approaches

### 2. **Assumption Buster** (@skills/assumption-buster)
- **Purpose**: Aggressively identify and disprove assumptions through counterexamples
- **Focus**: Finding where assumptions fail, edge cases, failure modes
- **When to use**: Critical systems, high-failure-cost scenarios, risk assessment
- **Output**: Busted assumptions, failure scenarios, risk areas

### 3. **Red Team** (@skills/redteam)
- **Purpose**: Think like an attacker to identify security vulnerabilities
- **Focus**: Security weaknesses, penetration vectors, attack paths
- **When to use**: Security assessments, penetration testing, defense preparation
- **Output**: Vulnerabilities, attack simulations, security recommendations

### 4. **White Hat** (@skills/white-hat)
- **Purpose**: Build defensive security capabilities and implement security by design
- **Focus**: Protective controls, security architecture, ethical testing
- **When to use**: Security implementation, compliance, defense building
- **Output**: Security controls, defense recommendations, security posture

### 5. **Trust But Verify** (@skills/trust-but-verify)
- **Purpose**: Independently verify claims rather than trusting assumptions
- **Focus**: Evidence validation, claim verification, reality checking
- **When to use**: Validating test results, progress claims, system capabilities
- **Output**: Verification results, discrepancies, confidence assessments

## Integrated Adversarial Thinking Workflow

### Phase 1: Challenge Foundation
1. **Devil's Advocate**: Challenge core ideas and reasoning
2. **Assumption Buster**: Identify and test foundational assumptions
3. **Trust But Verify**: Validate evidence and claims

### Phase 2: Stress Test Design
1. **Assumption Buster**: Find edge cases and failure modes
2. **Red Team**: Identify attack vectors and security weaknesses
3. **Devil's Advocate**: Challenge design decisions and alternatives

### Phase 3: Build Defenses
1. **White Hat**: Implement security controls and defenses
2. **Trust But Verify**: Validate defensive effectiveness
3. **Devil's Advocate**: Challenge defense completeness

### Phase 4: Continuous Improvement
1. **Trust But Verify**: Monitor and validate ongoing
2. **Red Team**: Regular security testing
3. **Assumption Buster**: Periodic assumption review

## When to Use Which Adversarial Perspective

### For Technical Decisions:
- **Architecture choices**: Devil's Advocate + Assumption Buster
- **Technology selection**: Devil's Advocate + Trust But Verify
- **Implementation details**: Assumption Buster + White Hat
- **Security design**: Red Team + White Hat

### For Product Decisions:
- **Feature prioritization**: Devil's Advocate + Assumption Buster
- **User experience**: Assumption Buster + Trust But Verify
- **Market strategy**: Devil's Advocate + Red Team (competitive analysis)
- **Business model**: Assumption Buster + Trust But Verify

### For Security Assessments:
- **Penetration testing**: Red Team primary, White Hat secondary
- **Security architecture**: White Hat primary, Red Team secondary
- **Incident response**: White Hat primary, Trust But Verify secondary
- **Compliance**: White Hat primary, Devil's Advocate secondary

### For Risk Management:
- **Risk identification**: Assumption Buster primary
- **Risk assessment**: Trust But Verify primary
- **Risk mitigation**: White Hat primary
- **Risk monitoring**: Trust But Verify primary

## Examples

```bash
# Full adversarial assessment of a new feature
npm run adversarial:full -- --feature "payment-processing" --phases all

# Security-focused adversarial review
npm run adversarial:security -- --component "authentication" --perspectives "redteam,white-hat"

# Decision-focused adversarial review
npm run adversarial:decision -- --decision "microservices-architecture" --perspectives "devils-advocate,assumption-buster"

# Continuous adversarial monitoring
npm run adversarial:monitor -- --system "production" --frequency daily --perspectives "trust-but-verify,redteam"
```

## Output format

```
Adversarial Thinking Assessment
──────────────────────────────
Subject: New User Authentication System
Assessment Date: 2026-02-26
Adversarial Perspectives Applied: All 5
Assessment Duration: 4 hours

Perspective Analysis:

1. Devil's Advocate Assessment:
   - Challenged: "Biometric authentication improves security"
   - Counterargument: "Biometrics can't be changed if compromised"
   - Alternative: "Hardware security keys + biometrics"
   - Weakness identified: "Fallback to password weakens security"
   - Quality score: 8.2/10 (thorough challenging)

2. Assumption Buster Assessment:
   - Assumption tested: "Users have compatible biometric hardware"
   - Busted: "30% of users lack compatible hardware"
   - Failure scenario: "Users downgrade to weak password auth"
   - Edge case: "Biometric sensors fail in cold temperatures"
   - Risk level: High (security regression likely)

3. Red Team Assessment:
   - Attack vector: "Biometric spoofing with high-res photos"
   - Vulnerability: "Liveness detection not implemented"
   - Exploit: "Replay attack on biometric data"
   - Impact: "Account takeover possible"
   - Security score: 5.8/10 (vulnerable)

4. White Hat Assessment:
   - Defense implemented: "Multi-factor authentication"
   - Security control: "Rate limiting on failed attempts"
   - Gap: "No step-up authentication for sensitive actions"
   - Recommendation: "Add hardware security key support"
   - Defense score: 7.1/10 (good but incomplete)

5. Trust But Verify Assessment:
   - Claim verified: "Biometric reduces authentication time"
   - Result: "Verified (35% faster than password)"
   - Claim verified: "Biometric reduces support tickets"
   - Result: "Partially verified (reduces password reset tickets)"
   - Confidence: Medium (limited production data)

Integrated Findings:

Critical Issues:
1. Security regression risk (biometric fallback to password)
2. Biometric spoofing vulnerability (no liveness detection)
3. Hardware compatibility exclusion (30% of users)

Strengths:
1. Multi-factor implementation solid
2. Performance improvement verified
3. User convenience likely improved

Recommendations by Priority:

HIGH PRIORITY:
1. Implement liveness detection for biometric authentication
2. Remove password fallback (use alternative methods)
3. Add hardware security key support for incompatible devices

MEDIUM PRIORITY:
4. Implement step-up authentication for sensitive actions
5. Add biometric failure rate monitoring
6. Conduct user education on biometric security

LOW PRIORITY:
7. Enhance audit logging for biometric attempts
8. Add geographic anomaly detection
9. Implement biometric template update mechanism

Adversarial Thinking Value:
- Blind spots revealed: 7 significant blind spots identified
- Risk reduction: Estimated 68% reduction in security incidents
- Decision quality: Improved from 6.5/10 to 8.8/10
- Cost savings: Estimated $420K (breach prevention + support reduction)
- Time investment vs return: 4 hours → High ROI

Next Steps:
1. Address high-priority recommendations before launch
2. Schedule follow-up adversarial assessment in 90 days
3. Establish continuous adversarial monitoring
4. Share findings with development and security teams
5. Update threat model based on adversarial findings

Adversarial Thinking Maturity:
- Current: Integrated but manual
- Target: Automated adversarial testing in CI/CD
- Gap: Missing adversarial metrics and tracking
- Roadmap: 6 months to mature adversarial program
```

## Notes

- Adversarial thinking is a system, not just occasional criticism
- Different adversarial perspectives complement each other
- Balance adversarial challenge with constructive improvement
- Document adversarial findings for organizational learning
- Use adversarial thinking to build resilience, not just find faults
- Regular adversarial practice prevents complacency
- The most valuable adversarial thinking challenges deeply held beliefs
- Measure adversarial thinking effectiveness over time
- Foster culture that welcomes adversarial perspectives
- Adversarial thinking should improve outcomes, not just criticize
- The best adversarial thinkers help build better solutions
- Integrate adversarial thinking into regular processes, not just special reviews