| 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?)
