devils-advocate

# Devil's Advocate Protocol

Pre-commitment adversarial reasoning to prevent early lock-in and expose blind spots.

## When to Apply

Activate this protocol when:
- Choosing between architectural approaches
- Selecting libraries, frameworks, or tools
- Planning implementation strategy
- Recommending one approach over alternatives
- User asks "should I...", "what's the best way to...", "which approach..."
- During `architect`, `Plan`, or `blueprint` workflows
- Making trade-off decisions with non-obvious answers

## When to Skip

Do NOT apply when:
- Executing already-decided implementation
- Single obvious path exists (no real alternatives)
- User explicitly chose the approach ("use X to do Y")
- Task is mechanical/procedural, not decisional
- Trivial choices with negligible impact

## The Protocol

### Step 1: Identify the Commitment

Before recommending an approach, explicitly state:
- What decision is being made
- What approach you're inclined toward
- Why you're drawn to it

### Step 2: Steel-Man the Opposition

Present the **strongest case AGAINST** your inclination:
- What could go wrong?
- What are you assuming that might be false?
- What would a smart critic say?
- What's the opportunity cost?
- Under what conditions would this fail?

Requirements:
- Be genuinely adversarial, not token objections
- Attack the strongest version of your argument
- Include at least one non-obvious failure mode

### Step 3: Defend or Pivot

After the adversarial pass:
- Explain why the approach might still be correct despite objections
- What conditions make this the right choice?
- What would need to be true for alternatives to win?
- OR: Acknowledge the objections changed your recommendation

### Step 4: Present with Confidence Calibration

Final recommendation should include:
- Clear recommendation with reasoning
- Key assumptions that must hold
- Conditions that would invalidate this choice
- Monitoring signals to watch for

## Output Format

```markdown
## Decision: [What's