thinking-steel-manning

What this skill does

# Steel-Manning

## Overview

Steel-manning is the opposite of straw-manning. Instead of attacking the weakest version of an opposing argument, you construct and address the strongest possible version. This leads to better decisions, more productive debates, and deeper understanding of trade-offs.

**Core Principle:** To truly evaluate an idea, argue against its best form. If you can defeat the strongest version, you've actually learned something.

## When to Use

- Design reviews
- Evaluating alternative approaches
- Conflict resolution
- Validating your own decisions
- Code review discussions
- Architecture debates
- When you disagree with someone's proposal
- Before rejecting an idea

Decision flow:

```
Disagreeing with a proposal?
  → Can you state their best argument? → no → STEEL-MAN FIRST
  → Are you attacking a weak version? → yes → CONSTRUCT STRONGER VERSION
  → Have you found the core insight? → no → DIG DEEPER

About to agree with the user's plan?
  → Have you stated the strongest case against it? → no → STEEL-MAN THE OPPOSING VIEW FIRST
```

This skill is the direct counter to **sycophancy** — the pull to validate whatever the user proposed. Before endorsing a plan, construct the best case *against* it; agreement that survives that is worth more than reflexive agreement.

## When NOT to Use

- **The matter is settled fact, not a position.** Don't steel-man a factual error, a security anti-pattern, or a violated requirement — correct it. Steel-manning is for genuine trade-offs and judgment calls, not for manufacturing a defense of something wrong.
- **You already agree for good, stated reasons.** If you've actually weighed it, don't perform a fake debate; say why you agree.
- **Trivial or fully reversible choices** where the cost of being wrong is near zero — the deliberation isn't worth the budget.
- **An emergency requiring immediate action** — steel-man the post-incident review, not the live fire.

## Trigger Card

Before rejecting a proposal or when you're inclined to just agree with the user:

1. **State the opposing case in its strongest form** — not the version that's easy to knock down. What would its best advocate say?
2. **Find what's actually true in it** — even if you reject the conclusion, what valid insight or concern does it surface?
3. **Engage that strongest version** — respond to what was actually claimed, not a weak version. If your position still holds, great; if not, update.

Skip for trivial or fully reversible choices where the cost of being wrong is near zero. In an emergency, steel-man the post-incident review, not the live fire.

## The Steel-Manning Process

### Step 1: Understand the Original Argument

Before improving, understand:

```markdown
## Original Proposal

Proposal: "We should rewrite the backend in Rust"

Stated reasons:
- Memory safety
- Better performance
- Modern language

Apparent weaknesses:
- Team doesn't know Rust
- Rewrite is risky
- Current system works
```

### Step 2: Identify the Core Insight

What's the strongest kernel of truth?

```markdown
## Core Insight

Behind "rewrite in Rust" is:
- Concern about memory-related bugs in production
- Performance problems that are hard to solve in current language
- Technical debt making changes slow

The proposal might be wrong, but the concerns are valid.
```

### Step 3: Construct the Strongest Version

Build the best possible case:

```markdown
## Steel-Manned Argument

"Our memory-safety issues have caused 3 major outages this year,
costing us ~$500K in engineering time and customer trust.
Our performance problems stem from GC pauses that are fundamental
to our current runtime. While a rewrite is risky, the incremental
cost of working around these limitations is growing.

A gradual rewrite of performance-critical paths to Rust would:
- Eliminate a class of bugs (memory safety)
- Solve GC-related latency issues
- Attract engineers who want modern tooling
- Create optionality for high-performance features

The risk can be mitigated by:
- Starting with one isolated service
- Keeping the team small and focused
- Maintaining the old system during transition
- Having clear rollback criteria"
```

### Step 4: Address the Steel-Manned Version

Now engage with the strongest argument:

```markdown
## Response to Steel-Manned Argument

The strongest case for Rust addresses real problems. However:

Memory safety issues:
- 2 of 3 outages were logic bugs, not memory bugs
- Could be addressed with better testing in current language
- Rust learning curve might introduce new bug classes

Performance:
- GC issues could be addressed with tuning
- Critical path is <5% of codebase
- FFI to native code is an option without full rewrite

The 6-month investment in Rust might be better spent:
- 2 months: Performance profiling and GC tuning
- 2 months: Targeted native extensions for hot paths
- 2 months: Improved testing/monitoring

This addresses the concerns with lower risk.
```

### Step 5: Find the Synthesis

What's the best answer considering both sides?

```markdown
## Synthesis

The Rust proposal was right about the problems, less right about the solution.

Agreed:
- Memory safety is a real concern (but smaller than stated)
- Performance needs improvement (but addressable incrementally)
- Technical modernization has value (but not at rewrite cost)

Plan:
1. Address immediate performance with profiling + tuning
2. Build one small service in Rust as learning experiment
3. Evaluate Rust for future services based on learnings
4. Don't rewrite existing system

This takes the best of both positions.
```

## Steel-Manning Patterns

### In Design Reviews

```markdown
## Design Review: Microservices Proposal

Weak version to avoid:
"They just want to use trendy tech"

Steel-manned version:
"The monolith has become a development bottleneck.
Deploy conflicts are causing delays. Different teams
need different scaling characteristics. The proposal
addresses real coordination problems."

Now address:
"The coordination problems are real, but can we solve them
with modular monolith patterns before taking on distributed
systems complexity?"
```

### In Code Reviews

```markdown
## Code Review: Complex Abstraction

Weak critique:
"This is over-engineered"

Steel-manned understanding:
"The author anticipated we'll need to support multiple
backends. This abstraction makes adding new backends
trivial. The complexity exists to serve future flexibility."

Better critique:
"I understand this enables multiple backends. Let's
validate that requirement—if we only ever need one,
the abstraction adds maintenance burden without benefit."
```

### In Conflict Resolution

```markdown
## Team Disagreement: Testing Strategy

Person A: "We need 100% code coverage"
Person B: "Code coverage is a vanity metric"

Steel-man A:
"Coverage ensures we think about edge cases and makes
refactoring safer. Without coverage requirements,
critical paths go untested."

Steel-man B:
"Coverage without quality gives false confidence.
Testing getters/setters wastes time better spent on
integration tests that catch real bugs."

Synthesis:
"Coverage is valuable for complex logic, less valuable
for trivial code. Let's require coverage for business
logic modules, but focus on integration tests for
overall system confidence."
```

### In Self-Critique

```markdown
## Validating My Own Decision

My decision: Use NoSQL for this project

Steel-man the opposite:
"SQL has survived 50 years because relational models
work for most data. NoSQL solves problems most projects
don't have. The flexibility of schemaless data becomes
a bug when requirements solidify. Joins are a feature,
not a limitation."

Now: Does my NoSQL choice survive this critique?
- Do I actually need schemaless flexibility?
- Will I regret not having joins?
- Am I solving a problem I don't have?
```

## Steel-Manning Red Flags

Signs you're straw-manning instead:

| Straw-Man Sign | Example | Fix |
|----------------|---------|-----|
| "They just want..." | "T