Constructive dissent

Constructive Dissent

Systematically challenge proposals through structured dissent protocols that expose weaknesses, test assumptions, and generate superior alternatives.

When to Use This Skill

• Before finalizing major decisions or architectural choices
• Testing proposals for hidden weaknesses and blind spots
• Generating alternative approaches not yet considered
• Auditing assumptions (explicit, implicit, and structural)
• Evaluating competing solutions with stakeholder perspectives
• Avoid using for routine code reviews — use requesting-code-review instead

Workflow

Step 1: Select Dissent Intensity

Choose the appropriate challenge level based on decision stakes:

Level	Purpose	When to Use
Gentle	Refine without challenging core approach	Low-stakes improvements, early drafts
Systematic	Challenge methods while respecting intent	Medium-stakes decisions, methodology review
Rigorous	Attack fundamental premises	High-stakes architecture, major pivots
Paradigmatic	Question worldview, propose radical alternatives	Strategic direction, innovation pursuit

Step 2: Run Assumption Audit

For the proposal under review, systematically identify:

1. Explicit assumptions — What's stated as given?
2. Implicit assumptions — What's unstated but operating?
3. Structural assumptions — What framework biases exist?
4. Temporal assumptions — What time constraints are artificial?

| Assumption | Type | Validity | Risk if Wrong |
|------------|------|----------|---------------|
| Users prefer speed over accuracy | Implicit | Medium | Product misalignment |
| API rate limits won't change | Temporal | Low | System failure at scale |

Step 3: Generate Edge Cases

Stress-test the proposal across dimensions:

• Scale extremes: What happens at 10x and 0.1x volume?
• Performance limits: Where does the approach break?
• User behavior extremes: Best-case and worst-case usage patterns
• Resource constraints: What if budget, time, or team shrinks by half?

Step 4: Apply Challenge Methodologies

Alternative Generation Framework:

1. Goal abstraction — Extract core objectives from the specific implementation
2. Constraint relaxation — Temporarily remove limitations to see what's possible
3. Method inversion — Consider the opposite approach
4. Cross-domain inspiration — Apply solutions from other fields

Stakeholder Advocacy — Argue from each perspective:

• End user, maintainer, security, accessibility, future stakeholder

Step 5: Synthesize and Recommend

Produce a structured analysis:

## Constructive Dissent Analysis: [Proposal Title]

### Intensity Level: [Selected Level]

### Executive Summary
[2-3 sentence summary of key challenges and recommendations]

### Challenges Raised
#### Challenge 1: [Title]
**Type**: Methodology / Premise / Evidence / Stakeholder
**Core Argument**: [What's being challenged and why]
**Evidence**: [Data or reasoning supporting the challenge]
**Alternative Approach**: [What to do instead]

### Generated Alternatives
#### Alternative 1: [Title]
**Approach**: [High-level description]
**Advantages**: [Why this might be better]
**Trade-offs**: [What you give up]

### Synthesis
- Strengthen current proposal: [specific improvements]
- Consider alternative if: [conditions that favor switching]
- Unresolved questions: [items needing more information]

Best Practices

• Match intensity to stakes — Paradigmatic dissent on a CSS tweak wastes everyone's time
• Preserve constructive framing — Challenge ideas, not people
• Always propose alternatives — Critique without alternatives is just criticism
• Document assumptions explicitly — Hidden assumptions are the highest-risk items
• Use stakeholder advocacy — Argue each perspective genuinely, not as a strawman