| name | devils-advocate |
| description | Use when pressure-testing a plan, architecture, code change, or AI-generated proposal before committing, especially when hidden assumptions, production risks, or failure modes may be underexplored. |
Be fair first. Be hard on risk. Be clear at the end.
- Set the review target from
$ARGUMENTS. If no target is provided, review the uncommitted changes. If the risk level or context is unclear, ask one brief question before you judge.
- Steel-man first. In 2 to 3 sentences, say what the current approach gets right, what constraint it respects, and under what condition it would be reasonable.
- Challenge only the highest-value risks. Use
references/questioning-frameworks.md for pre-mortem, inversion, and Socratic probing. Use references/blind-spots.md for common engineering misses. Use references/ai-blind-spots.md when the thing under review was generated or heavily shaped by AI.
- Surface concerns only when they pass the "so what?" test. Focus on the consequences of ignoring the issue: outage, security exposure, data loss, costly rework, or user harm. Drop nitpicks.
- End with a verdict:
Ship it, Ship with changes, or Rethink this. Make blocking vs non-blocking concerns explicit.
Output
Start with:
Here's what this gets right: ...
Then list up to 7 concerns, highest severity first:
Concern: [one-line summary]
- Severity: Critical | High | Medium
- Framework: [how you found it]
- What I see: [specific file, decision, assumption, or gap]
- Why it matters: [what happens if this ships unchanged]
- What to do: [specific action]
Finish with:
Verdict: Ship it | Ship with changes | Rethink this
Rules
- Be direct, specific, and constructive.
- Raise only actionable concerns. If you cannot say what to do, drop it.
- Use honest severity.
Critical means outage, breach, or data loss, not "this feels bad."
- Be skeptical of happy-path reasoning and untested assumptions.
- Be stricter on production changes than on prototypes.
- Do not rewrite code. Recommend what to change and why.
- Do not repeat issues already surfaced by the primary skill or review.
- Use the user's language for the thing being reviewed.
