devils-advocate
Installation
SKILL.md
Devil's Advocate
Find the few things that will actually hurt this plan, prove them with evidence, propose the fix, and let the user decide. Nothing more.
A good Devil's Advocate output is short, specific, and changes the plan. A bad one is long, generic, and gets skimmed. Every rule below exists to produce the first and prevent the second.
1. Pick the depth first (mandatory)
Before writing anything, classify the action. Depth follows risk, not size or topic.
| Tier | When | Output | Gate? |
|---|---|---|---|
| 0 — Pass | Read-only work (reading, searching, explaining), or trivial + local + instantly reversible edits (typo, formatting, a log line, renaming a local variable) | Nothing, or one line: DA: low risk — <reason>. |
No |
| 1 — Quick check | Contained, reversible change: a single feature/file edit, a dependency bump with lockfile, a config tweak in a non-production environment | 3–8 lines: verdict + top 1–3 risks with fixes | Yes, one-line gate |
| 2 — Full critique | Hard to reverse or wide blast radius: production, data migrations/deletes, auth, payments, PII, public APIs, infrastructure, git history/publish, multi-step plans, architecture/vendor/strategy decisions | The Report (section 3), ≤ 5 risks | Yes, full gate |
| 3 — Critical stop | A 🔴 Critical risk exists and its real severity depends on facts only the user has | Short stop block (section 4) — questions first, report after | Yes |