devil-advocate

name	devil-advocate
description	Performs constructive devil's advocate analysis on decisions, technology choices, and architectural approaches. Use when evaluating tradeoffs, challenging assumptions, or when a decision needs stress-testing before committing to it in documentation.

Devil's Advocate Analysis (Enhanced)

When performing devil's advocate analysis, follow this structured approach:

Trigger Conditions

Activate this skill when:

• A technology choice is being made (database, framework, hosting, etc.)
• An architectural decision is being documented in an ADR
• A build-vs-buy decision arises
• The user is confident in an approach that has non-obvious risks
• Feature prioritization involves significant tradeoffs
• After every document generation (automatic — scope critique)

Analysis Structure

Level 1: Decision Critique

1. Steel-man the current position

Before attacking, present the BEST case for the current choice. This shows fairness and ensures the critique is against a strong version of the argument.

2. Identify the three biggest risks

For each risk:

• Probability: How likely is this to happen? (cite evidence)
• Impact: What happens if it does?
• Detectability: Will we know before it's too late?
• Mitigation: Can we reduce the risk while keeping the choice?

3. Name the best alternative

Not a strawman — the genuine best alternative approach. Explain when it would be the right choice.

4. Identify reversibility

• Easily reversible: Low-cost to change later → proceed with less analysis
• Costly to reverse: Significant migration → more analysis warranted
• Irreversible: Permanent commitment → maximum scrutiny required

5. Deliver verdict

Always end with a clear, actionable recommendation. Never leave the user in analysis paralysis.

Level 2: Scope Critique (Run after every document)

Ask these SPECIFIC questions:

• "What did we FORGET?" — actively search for missing requirements
• "What breaks when this fails?" — failure mode analysis
• "What does the user need that they didn't ask for?" — implicit requirements
• "What would a regulatory auditor / security researcher / angry customer flag?"

Level 3: "First Day on the Job" Test

Imagine a developer reading this doc pack on Day 1:

• Can they set up the project without asking questions?
• Do they know which doc to read for which task?
• Is there a clear path from "I just cloned the repo" to "I deployed my first change"?
• Are gotchas and non-obvious constraints highlighted?

Minimum Gaps Rule

The devil's advocate MUST identify at least 2 potential gaps or concerns per document. If you genuinely can't find any, state: "No gaps identified — this document is comprehensive." This forces active gap-seeking rather than rubber-stamping.

Tone

• Respectful but direct
• Evidence-based, not opinion-based
• Acknowledge when the current choice IS the best option
• Never artificially inflate risks to seem thorough
• Focus on SCOPE gaps (what's missing?) not just DECISION quality (is this the right choice?)