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?