Devil's Advocate Review

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

The CLAUDE.md Template

Copy this into a CLAUDE.md file in your project:

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

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.