Help us improve
Share bugs, ideas, or general feedback.
From codex-collab
This skill should be used when the user wants to "stress-test a design", "challenge an idea", "red team a proposal", "get critical feedback on a design", "validate a design", "adversarial architecture review", "risk assessment", "設計を検証して", "反論をもらいたい", "設計を批判的にレビュー", "デビルズアドボケート", "ストレステスト", "弱点を指摘して", "穴を見つけて", "この設計で良いか", "リスク評価", "設計のアーキテクチャレビュー", or mentions structured adversarial review of a proposal or design. NOTE: Use this for validating PROPOSALS and DESIGNS through adversarial debate, NOT for generic code review, PR review, or normal review requests (use codex-collab for those). Also NOT for investigating unknown bugs (use strong-inference for that).
npx claudepluginhub masup9/codex-collab --plugin codex-collabHow this skill is triggered — by the user, by Claude, or both
Slash command
/codex-collab:devils-advocateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Apply the Devil's Advocate methodology to stress-test hypotheses, designs, and proposals through structured adversarial debate.
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
Apply the Devil's Advocate methodology to stress-test hypotheses, designs, and proposals through structured adversarial debate.
Devil's Advocate is a critical thinking technique that improves decision quality by:
This skill helps developers validate designs, proposals, and decisions using a structured Blue Team (propose/defend) vs Red Team (critique/challenge) approach.
Key Feature: In codex mode, this skill leverages Codex as the Red Team critic while Claude serves as the Blue Team advocate.
| Aspect | Strong Inference | Devil's Advocate |
|---|---|---|
| Purpose | Verify hypothesis through experiments | Stress-test proposal through debate |
| Method | Competing hypotheses + decisive experiments | Adversarial critique + iterative refinement |
| Output | Root cause with evidence trail | Refined proposal with verdict |
| Best For | Debugging, investigation, unknown causes | Design review, decision validation, risk assessment |
codex exec)When the user presents a proposal:
Collect information:
Clarify scope:
Present and defend the proposal:
Challenge the proposal systematically:
Concerns are categorized by severity:
Respond to Red Team critique:
Red Team reassesses:
After all rounds, Red Team provides:
APPROVE: No critical issues, proposal is sound
CONDITIONAL: Proceed with specific conditions
REJECT: Fundamental issues require redesign
| Mode | Blue Team | Red Team |
|---|---|---|
codex | Claude | Codex |
claude-only | Claude | Claude |
codex (when Codex CLI available)claude-only (automatic when Codex unavailable)Debate state is persisted to tmp/devils-advocate/<task-id>.md:
---
schema: devils-advocate/v1
task_id: abc123
created: 2026-02-03T12:00:00Z
proposal: "Add caching layer to API responses"
mode: codex
round: 2
max_rounds: 3
status: in_progress
verdict: pending
---
# Red Team Review: Add caching layer to API responses
## Overview
**Proposal:** Add caching layer to API responses
**Mode:** codex
**Max Rounds:** 3
## Debate Log
### Round 1
#### Blue Team (Claude)
**Position:**
We should add a Redis-based caching layer to reduce database load...
**Key Points:**
1. 80% of requests are read-only and cacheable
2. Expected 60% reduction in DB queries
3. TTL-based invalidation for simplicity
#### Red Team (Codex)
**Key Concerns:**
1. **[Severity: High]** Cache invalidation complexity
- Issue: Write operations may leave stale data
- Impact: Users see outdated information
- Suggestion: Implement cache-aside with explicit invalidation
2. **[Severity: Medium]** Redis as single point of failure
- Issue: Redis downtime affects entire API
- Impact: Service degradation
- Suggestion: Add fallback to direct DB queries
### Round 2
...
The debate process includes:
Devil's Advocate Review
=======================
Proposal: Add caching layer to API responses
Round 2 of 3
Status: Blue Team defending
Current concerns:
[!] High: Cache invalidation complexity (Addressed)
[?] Medium: Redis SPOF (Pending response)
[X] Low: Documentation needs (Addressed)
Devil's Advocate Review Complete
================================
Proposal: Add caching layer to API responses
Verdict: CONDITIONAL
Summary:
The caching proposal is sound with modifications. Blue Team
adequately addressed invalidation concerns by switching to
cache-aside pattern. Redis SPOF concern requires fallback.
Conditions:
1. Implement fallback to direct DB queries when Redis unavailable
2. Add cache hit/miss metrics for monitoring
Remaining Risks:
- Cache stampede during cold start (Low)
- Memory pressure under high cardinality (Low)
Recommendations:
- Proceed with implementation
- Address conditions before production deployment
- Monitor closely during initial rollout
Use the /devils-advocate command:
# Basic usage - stress-test a design
/devils-advocate Add a caching layer to reduce database load
# With mode selection
/devils-advocate --mode claude-only Should we migrate to microservices?
# With custom rounds
/devils-advocate --max-rounds 5 This authentication redesign
# Japanese
/devils-advocate この認証設計を批判的にレビューして
Detailed templates in references/:
critique-prompt.md - Template for Red Team critique generationevaluation-criteria.md - Detailed verdict criteria