Challenge That
Force critical evaluation by analyzing from multiple adversarial perspectives.
When to Use
Invoke /challenge-that when:
- Claude accepted a proposal without critical evaluation
- You want to stress-test a decision before committing
- Requirements feel under-examined
- Something seems off but you can't articulate why
The Five Hats
Each perspective challenges from a different angle:
| Hat | Focus | Key Questions |
|---|---|---|
| 🔴 Skeptic | Evidence & proof | "What evidence supports this? Has this been validated? Are we guessing?" |
| 🟡 Pragmatist | Cost/benefit | "Is this the simplest fix? What's the maintenance burden? Is it worth it?" |
| 🟢 Edge Case Hunter | Failure modes | "What breaks this? What's the worst case? What did we miss?" |
| 🔵 Structural Critic | Architecture | "Is this the right location? Does it fit the existing design? Will it cause problems elsewhere?" |
| 🟣 Root Cause Analyst | Problem diagnosis | "Is the problem correctly identified? Are we treating symptoms? What's the actual cause?" |
Behavior
When /challenge-that is invoked:
- Identify what was just accepted/proposed
- State it clearly: "Challenging: [the proposal/decision]"
- Analyze from each of the five perspectives
- Synthesize into actionable concerns
- Ask: "Which concerns should we address before proceeding?"
Output Format
## Challenging: [proposal/decision being challenged] ### 🔴 Skeptic [Challenge from evidence/proof perspective] ### 🟡 Pragmatist [Challenge from cost/benefit perspective] ### 🟢 Edge Case Hunter [Challenge from failure modes perspective] ### 🔵 Structural Critic [Challenge from architecture perspective] ### 🟣 Root Cause Analyst [Challenge from problem diagnosis perspective] --- **Key Concerns:** 1. [Most significant concern] 2. [Second concern] 3. [Third concern] Which of these should we address before proceeding?
Critical Rules
🚨 Be genuinely adversarial. Don't softball the challenges. If a perspective finds nothing wrong, say so—but look hard first.
🚨 Challenge the proposal, not the person. Focus on the idea's weaknesses, not who suggested it.
🚨 Provide actionable output. Each challenge should point to something that could be investigated or changed.
Example
User: /challenge-that
Context: Claude just accepted a proposal to add edge case validation to TDD's GREEN state.
Output:
Challenging: Add edge case validation checklist to TDD GREEN state
🔴 Skeptic
What evidence shows that GREEN state is the right location? The proposal assumes this will catch bugs, but has anyone tested whether developers actually use checklists at this stage? GREEN means "tests pass"—adding a review step here changes what GREEN means.
🟡 Pragmatist
This adds friction to every TDD cycle. Is the bug frequency high enough to justify the overhead? The PR mentioned 3 bugs in one PR—is that representative or an outlier? What's the cost of false negatives (checklist fatigue)?
🟢 Edge Case Hunter
What happens when the checklist reveals missing tests? There's no GREEN → PLANNING transition. The developer would need to either ignore the finding or break the state machine. This creates a dead end.
🔵 Structural Critic
GREEN state is about code quality assessment, not test coverage. Test writing happens in PLANNING. This checklist belongs in PLANNING state where tests are actually written—not after they've already passed.
🟣 Root Cause Analyst
The actual problem was insufficient edge case consideration during test writing. The proposal treats the symptom (bugs shipped) not the cause (incomplete test planning). Moving this to PLANNING would address the root cause.
Key Concerns:
- GREEN is structurally the wrong location—no recovery path exists
- Root cause is in PLANNING, not GREEN
- No evidence this will be used effectively at GREEN stage
Which of these should we address before proceeding?
