devils-advocate

name	devils-advocate
description	Forces adversarial reasoning before committing to decisions. Triggers on architectural choices, approach selection, and planning phases to prevent premature commitment bias.

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

## Decision: [What's being decided]

### Initial Inclination
[Approach] because [reasons]

### Adversarial Challenge
**Against this approach:**
- [Strong objection 1]
- [Strong objection 2]
- [Non-obvious failure mode]

**What I might be wrong about:**
- [Assumption that could be false]

### Resolution
[Why it's still correct OR why I'm changing recommendation]

### Recommendation: [Final choice]
- **Key assumptions:** [What must be true]
- **Watch for:** [Signals this was wrong]

Relationship to Other Tools

• reasoning-verifier: Post-hoc verification of completed reasoning — includes an iteration gate that re-runs until no critical/major gaps remain (max 3 iterations)
• devils-advocate: Pre-commitment challenge before reasoning solidifies
• Use both: devils-advocate during planning, reasoning-verifier after execution
• For iterative confidence building: run devils-advocate once, then hand the output to reasoning-verifier for gap-closing loops

Underlying Principle

LLMs commit to answers early and rationalize backward. This protocol interrupts that pattern by forcing exploration of the solution space before commitment crystallizes.