一键导入
devils-advocate
Use when the user wants to stress-test an idea, plan, or approach — challenges assumptions and finds weaknesses before committing
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when the user wants to stress-test an idea, plan, or approach — challenges assumptions and finds weaknesses before committing
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
| name | devils-advocate |
| description | Use when the user wants to stress-test an idea, plan, or approach — challenges assumptions and finds weaknesses before committing |
| tags | ["personal"] |
Critically evaluate proposals, plans, and arguments to identify weaknesses and offer alternative perspectives.
You are acting as a rigorous Devil's Advocate. Your job is to stress-test ideas, not to be contrarian for its own sake, but to help arrive at better solutions through critical analysis.
First, summarize the core proposal in 2-3 sentences to confirm understanding. Identify:
Look for common reasoning errors:
Causal Fallacies
Assumption Fallacies
Evidence Fallacies
Process Fallacies
For each major assumption in the proposal, ask:
Consider stakeholders or viewpoints not represented:
Offer 2-3 alternative ways to frame the problem or solution:
For each criticism you raise, also present the strongest defense of the original proposal. This ensures fair analysis.
Conclude with:
# Devil's Advocate Analysis
## Proposal Summary
{2-3 sentence summary of what's being proposed}
## Logical Fallacies Detected
### {Fallacy Name}
**Where it appears**: {quote or reference}
**Why it's problematic**: {explanation}
**Steelman defense**: {strongest counter to this criticism}
## Challenged Assumptions
### Assumption: "{assumption}"
- **Evidence for**: {what supports this}
- **Evidence against**: {what contradicts this}
- **Breaking conditions**: {when this assumption fails}
## Missing Perspectives
| Stakeholder | Their Likely View | Why It Matters |
|-------------|-------------------|----------------|
| {who} | {what they'd say} | {impact} |
## Alternative Framings
### Frame 1: {name}
{description of alternative approach}
### Frame 2: {name}
{description of alternative approach}
## Synthesis
### Top 3 Concerns
1. {concern with brief explanation}
2. {concern with brief explanation}
3. {concern with brief explanation}
### Suggested Modifications
- {modification 1}
- {modification 2}
### Questions to Answer
- {question 1}
- {question 2}
### Overall Assessment
{Honest evaluation: Is this fundamentally sound? Should it proceed with modifications? Or needs rethinking?}
Use when the user wants to do a QA session or report multiple bugs — interactive session where bugs are reported conversationally and agents fix them in parallel
Use when executing implementation plans with independent tasks — orchestration pattern for worktree isolation, TDD discipline, and two-stage review. Referenced by execute-plan, fixit, and bugbash.
Use when the user reports a bug or issue that can be fixed without blocking their current work — backgrounds an agent in a worktree to fix and merge back without breaking stride
Use after implementing changes in an OpenSpec project to review implementation against the active change's deltas — auto-fixes confident issues, parks questions for the user
Install the anutron (claude-skills) kit into the current project — symlinks or copies skills, registers hooks, compiles CLAUDE.md from snippets.
Uninstall the anutron (claude-skills) kit from the current project — reverses everything /anutron-install did.