reasoning-dialectical

What this skill does

# Dialectical Reasoning

Synthesize opposing views into higher-order resolution. The logic of productive disagreement.

## Type Signature

```
Dialectical : Thesis → Antithesis → Synthesis

Where:
  Thesis     : Position × Evidence × Stakeholder → ArgumentA
  Antithesis : ArgumentA → CounterPosition × Evidence × Stakeholder → ArgumentB
  Synthesis  : (ArgumentA, ArgumentB) → IntegratedPosition × Tradeoffs
```

## When to Use

**Use dialectical when:**
- Stakeholders hold opposing valid positions
- Trade-offs need explicit analysis
- Strategic tension requires resolution
- Multiple perspectives each have merit
- "On one hand... on the other" situations

**Don't use when:**
- Cause-effect chain needed → Use Causal
- Explaining observation → Use Abductive
- Evaluating past decisions → Use Counterfactual

## Core Principles

### Charitable Interpretation

Each position must be represented at its strongest:
- Steel-man, don't straw-man
- Assume good faith and valid reasoning
- Identify the kernel of truth in each view

### Genuine Synthesis

Synthesis is NOT:
- Compromise (splitting the difference)
- Victory (one side wins)
- Avoidance (postpone decision)

Synthesis IS:
- Integration at higher level of abstraction
- Resolution that addresses underlying concerns
- New position that transcends original framing

## Three-Stage Process

### Stage 1: Thesis

**Purpose:** Articulate first position at maximum strength.

**Components:**
```yaml
thesis:
  position: 
    statement: "Core claim being made"
    underlying_concern: "What this position is really about"
    
  stakeholder:
    who: "Person/team holding this view"
    role: "Their organizational function"
    incentives: "What they optimize for"
    
  evidence:
    supporting:
      - claim: "Evidence point"
        source: "Where this comes from"
        strength: 0.0-1.0
    empirical: [DataPoint]
    logical: [Argument]
    
  implications:
    if_adopted: "What happens if we go this way"
    risks: [Risk]
    benefits: [Benefit]
```

**Example:**
```yaml
thesis:
  position:
    statement: "We should prioritize enterprise features over SMB growth"
    underlying_concern: "Revenue concentration and deal size efficiency"
    
  stakeholder:
    who: "Sales leadership"
    role: "Revenue generation"
    incentives: "ARR, deal size, quota attainment"
    
  evidence:
    supporting:
      - claim: "Enterprise deals average $400K vs SMB $5K"
        source: "Q3 sales data"
        strength: 0.95
      - claim: "Sales cost per $ revenue 5x lower for enterprise"
        source: "CAC analysis"
        strength: 0.85
    empirical:
      - "3 enterprise deals = entire SMB revenue"
      - "Enterprise churn 3% vs SMB 8%"
      
  implications:
    if_adopted: "Focus engineering on enterprise features, reduce SMB investment"
    risks: 
      - "Lose SMB market to competitors"
      - "Revenue concentration risk"
    benefits:
      - "Higher margins"
      - "Larger average deal"
```

### Stage 2: Antithesis

**Purpose:** Articulate counter-position at maximum strength.

**Process:**
1. Identify what thesis misses or undervalues
2. Find stakeholder with opposing view
3. Build strongest case for alternative
4. Identify where thesis assumptions break

**Components:**
```yaml
antithesis:
  position:
    statement: "Counter claim"
    underlying_concern: "What this position is really about"
    
  stakeholder:
    who: "Person/team holding this view"
    role: "Their organizational function"
    incentives: "What they optimize for"
    
  critique_of_thesis:
    - assumption_challenged: "Thesis assumes X"
      counter_evidence: "But actually Y"
    - risk_identified: "Thesis ignores Z"
      
  evidence:
    supporting: [EvidencePoint]
    empirical: [DataPoint]
    logical: [Argument]
    
  implications:
    if_adopted: "What happens if we go this way"
    risks: [Risk]
    benefits: [Benefit]
```

**Example:**
```yaml
antithesis:
  position:
    statement: "SMB volume creates the foundation for sustainable growth"
    underlying_concern: "Market presence, product iteration, and risk distribution"
    
  stakeholder:
    who: "Product leadership"
    role: "Product-market fit and growth"
    incentives: "Usage, retention, feature validation"
    
  critique_of_thesis:
    - assumption_challenged: "Enterprise features drive growth"
      counter_evidence: "SMB usage generates product insights 10x faster"
    - assumption_challenged: "Revenue concentration is acceptable"
      counter_evidence: "Losing 1 enterprise deal = losing 80 SMB accounts"
    - risk_identified: "Enterprise sales cycle is 9 months"
      
  evidence:
    supporting:
      - claim: "SMB accounts generate 80% of feature requests"
        source: "Product feedback analysis"
        strength: 0.90
      - claim: "SMB provides faster iteration cycles"
        source: "Release metrics"
        strength: 0.85
    empirical:
      - "SMB churn prediction accuracy 95% vs enterprise 60%"
      - "Product improvements from SMB feedback shipped in 2 weeks"
      
  implications:
    if_adopted: "Maintain SMB investment, use as product lab"
    risks:
      - "Slower revenue growth short-term"
      - "Lower margin overall"
    benefits:
      - "Diversified revenue base"
      - "Faster product iteration"
      - "Lower concentration risk"
```

### Stage 3: Synthesis

**Purpose:** Integrate positions at higher level, resolving underlying tensions.

**Synthesis Approaches:**

| Approach | When to Use | Example |
|----------|-------------|---------|
| **Integration** | Both positions address valid concerns | "Enterprise revenue + SMB as product lab" |
| **Sequencing** | Temporal resolution possible | "SMB first for PMF, then enterprise scale" |
| **Segmentation** | Different contexts warrant different approaches | "SMB for product X, Enterprise for product Y" |
| **Reframing** | Original dichotomy was false | "The real question isn't SMB vs Enterprise, it's time-to-value" |
| **Transcendence** | Higher goal subsumes both | "Optimize for sustainable unit economics regardless of segment" |

**Synthesis Components:**
```yaml
synthesis:
  integrated_position:
    statement: "What we will actually do"
    framing: "How this resolves the tension"
    
  how_thesis_is_addressed:
    concern_validated: "What's true about thesis"
    how_incorporated: "How we address that concern"
    
  how_antithesis_is_addressed:
    concern_validated: "What's true about antithesis"
    how_incorporated: "How we address that concern"
    
  trade_offs_acknowledged:
    - trade_off: "What we're giving up"
      mitigation: "How we reduce impact"
      accepted_by: "Stakeholder who accepts this"
      
  resolution_type: integration | sequencing | segmentation | reframing | transcendence
  
  implementation:
    actions: [Action]
    metrics: [Metric]  # How we know it's working
    review_date: date  # When we reassess
```

**Example:**
```yaml
synthesis:
  integrated_position:
    statement: "SMB as rapid learning engine, enterprise as revenue engine, 
                with explicit feature graduation path"
    framing: "Not SMB vs Enterprise, but learning velocity vs revenue efficiency 
              with a bridge between them"
              
  how_thesis_is_addressed:
    concern_validated: "Enterprise deals are more efficient per dollar"
    how_incorporated: "Maintain enterprise sales motion, prioritize enterprise 
                       features that have been validated through SMB"
                       
  how_antithesis_is_addressed:
    concern_validated: "SMB generates faster product learning"
    how_incorporated: "Protect SMB investment as product lab, use SMB metrics 
                       to prioritize enterprise features"
                       
  trade_offs_acknowledged:
    - trade_off: "Some enterprise-only features will ship slower"
      mitigation: "Identify 'must have' enterprise features, fast-track those"
      accepted_by: "Sales leadership (with fa