Devil's Advocate Review
Challenge your designs and decisions with 5-7 targeted critical questions. Catches unstated assumptions, alternative approaches, and potential issues before you commit.
Everyone on your team agrees the plan is great, but nobody asked the hard questions. The assumptions go unchallenged, the edge cases go unmentioned, and the problems show up six weeks into implementation.
Who it's for: tech leads evaluating architecture decisions, product managers validating feature plans, founders pressure-testing strategies, engineers reviewing design docs before implementation, anyone making high-stakes decisions without a skeptic in the room
Example
"Challenge our decision to migrate from monolith to microservices" → 6 targeted critical questions exposing unstated assumptions about team size, data consistency trade-offs, and operational complexity — with alternative approaches you hadn't considered
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Devil's Advocate Protocol
## Purpose
Challenge designs and decisions before they become expensive mistakes. The Devil's Advocate role is adversarial by design — its job is to find weaknesses, not to be agreeable.
## Invoking the Devil's Advocate
Say: "Create a Devil's Advocate. Challenge [this design/decision/plan] with 5-7 specific questions."
## Devil's Advocate Rules
1. **Be specific**: "Have you considered X?" not "Are you sure about this?"
2. **Challenge assumptions**: What are we taking for granted?
3. **Propose alternatives**: "What if you did Y instead of X?"
4. **Consider failure modes**: "What happens when Z goes wrong?"
5. **Think about scale**: "Will this work with 10x/100x users/data?"
6. **Question necessity**: "Do you actually need this feature/complexity?"
7. **Check consistency**: "Doesn't this contradict your approach to [related thing]?"
## Question Categories
### Assumption Challenges
- "You're assuming [X]. What if that's wrong?"
- "This depends on [Y] being true. How confident are you?"
### Alternative Approaches
- "Have you considered [simpler approach]?"
- "What if you solved this at a different layer?"
- "Could you avoid this entirely by [alternative]?"
### Failure Mode Analysis
- "What happens when [common failure]?"
- "How does this behave under [edge case]?"
- "What's your recovery path if [thing] fails?"
### Scale Questions
- "Does this work with 10x the data?"
- "What's the complexity as N grows?"
- "Where are the bottlenecks?"
### Necessity Questions
- "Is this feature actually needed?"
- "Could you ship without this?"
- "Are you over-engineering?"
### Consistency Questions
- "Doesn't this conflict with [other decision]?"
- "You handled [similar case] differently. Why?"
## Response Protocol
After generating challenges:
1. Present all 5-7 questions
2. Let user respond to each
3. Work through responses together
4. Identify which challenges hold up
5. Revise design based on surviving challenges
## Output Format
```
## Devil's Advocate: [Topic]
**Challenge 1**: [Question]
*Why it matters*: [Brief context]
**Challenge 2**: [Question]
*Why it matters*: [Brief context]
... (5-7 total)
---
Work through each challenge. Which ones require design changes?
```
What This Does
Before committing to a design or implementation, invoke the Devil's Advocate to challenge it with 5-7 specific, probing questions. This catches unstated assumptions, identifies alternatives you didn't consider, and surfaces potential issues early — when they're cheap to fix.
Prerequisites
- Claude Code installed and configured
- A design, plan, or implementation to challenge
Devil's Advocate: [Topic]
Challenge 1: [Question] Why it matters: [Brief context]
Challenge 2: [Question] Why it matters: [Brief context]
... (5-7 total)
Work through each challenge. Which ones require design changes?
Step-by-Step Setup
Step 1: Add to your CLAUDE.md
Add the Devil's Advocate protocol to your project's CLAUDE.md.
Step 2: Practice on a current design
Think of a design decision you're about to make or recently made:
Create a Devil's Advocate. Challenge my decision to use Redux for state management in this React app.
Step 3: Work through the challenges
For each challenge, either:
- Defend your decision with a concrete reason
- Acknowledge the weakness and adjust
- Note it as a known tradeoff
Example Usage
User:
"Create a Devil's Advocate. Challenge my plan to build a custom authentication system instead of using Auth0."
Claude:
Devil's Advocate: Custom Auth vs Auth0
Challenge 1: Do you have the security expertise to implement password hashing, session management, and token validation correctly? Why it matters: Auth is a solved problem, and custom implementations frequently have subtle vulnerabilities.
Challenge 2: How will you handle MFA, social logins, and enterprise SSO when customers inevitably ask for them? Why it matters: Auth0 provides these out of the box. Custom implementations often become feature-request treadmills.
Challenge 3: What's your recovery plan when (not if) you discover a security vulnerability in your auth code? Why it matters: Auth0 has a security team patching issues. You'll be debugging at 2 AM.
Challenge 4: You estimated 2 weeks for auth. How does that compare to Auth0 integration (typically 1-2 days)? Why it matters: Those 2 weeks could build revenue-generating features.
Challenge 5: Your team has 3 developers. Is maintaining custom auth a good use of ongoing capacity? Why it matters: Auth isn't "done" — it requires ongoing security updates, password reset flows, rate limiting updates, etc.
Challenge 6: What's your actual objection to Auth0? Is it cost, control, or something else? Why it matters: The real reason might be addressable without building custom.
Work through each challenge. Which ones require reconsideration?
User:
"Challenge 2 and 5 are strong points. We will eventually need SSO for enterprise customers. Let me reconsider Auth0."
Tips
- Invoke early: Challenge designs when they're sketches, not after you've built them.
- Don't get defensive: The Devil's Advocate is helping you, not attacking you.
- Some challenges won't hold up: That's fine. The goal is to surface issues, not invalidate everything.
- Use for decisions, not just code: Works for product decisions, architecture, process changes, etc.
- Ask for specific angles: "Challenge this from a security perspective" or "Challenge the UX of this flow."
Troubleshooting
Problem: Challenges feel too generic
Solution: Provide more context about your design. Include constraints, alternatives you considered, and why you chose this approach.
Problem: Too many challenges, overwhelming
Solution: Ask for "your top 3 most serious challenges" instead of 5-7.
Problem: Challenges miss the real issues
Solution: Add domain context to your CLAUDE.md. If Claude doesn't know your users are mostly mobile, it won't challenge desktop-first assumptions.