# Devil's-Advocate Skill (Vanilla Reference)

Adversarially review a plan, design, or diff *before* committing to it — assume it is flawed and go find the real problems.

> Vanilla reference skill — adapt the placeholders to your project.

---

## Mindset: a rigorous critic, not a contrarian

You are not here to disagree for its own sake. You are here to find the problems that a normal, agreeable review would miss.

- **A devil's advocate who cries wolf loses credibility.** Manufacture a concern and the next ten get ignored. Raise only genuine issues.
- Look *harder* than a normal reviewer, but hold a *higher* bar for what you report. The two go together: the deeper you dig, the more careful you must be that what surfaces is real.
- Assume the plan is flawed and try to prove it. If you honestly can't, that is a finding too — say so plainly.

## When to run it

Run this pass **before the plan reaches a human**. The point is to catch the flaw while it is still cheap to fix — before anyone builds on it or signs off. Fold every valid concern back into the plan, then present the corrected version. A concern the human never has to see because you already resolved it is the ideal outcome.

Run it a second time **after a diff exists**, against the same lens — a plan that read as sound can still be built wrong.

## Interrogation checklist

Walk the plan (or diff) against these. Each is a place real defects hide.

- **Does each task actually achieve the stated goal?** Read the summary's intent, then read each task against it. If the summary says "*X* is the source of truth" but a task quietly keeps the old pattern alive — via a cast, a shim, or a parallel type — flag the contradiction. The task can look done and still not deliver the goal.
- **Is there a scope gap** between the summary's ambition and the tasks' actual scope? Ambition that no task implements is a hole. Name what the summary promises that nothing delivers.
- **Does any task edit a shared component or symbol without enumerating ALL of its consumers?** A change to something many things depend on must list every caller it touches. An un-enumerated consumer is an un-tested consumer.
- **Is a cast removed while a parallel or duplicate type is kept?** That is half a fix. The duplicate will drift from the real type and reintroduce the bug later. A real fix removes the duplication, not just the symptom.
- **Are sensitive surfaces under-scoped?** Authentication, payments, outbound messaging, data capture, rate-limiting and abuse-prevention all deserve extra suspicion. A change that touches one of these and treats it as routine is itself a finding.

## Verify before you raise

Every load-bearing factual sub-claim gets checked **by you**, first-hand, before it appears in your output. Search for the symbol. Read the callers. Open the file. Do not raise a concern that rests on an assumption you never confirmed — that is exactly how a devil's advocate cries wolf.

**Separate the *concern* from its *premise*.** A concern can be right even when the reason you first reached for it is wrong.

- The *concern* — "this shared change might break an un-listed consumer" — is worth adopting.
- The *premise* — "this file is already committed," "that symbol has no other caller," "this value can never be null" — must be re-verified before you fold the fix in.

Adopt the concern; re-check the premise. If the premise turns out false, the concern may dissolve — or may survive for a different reason you now understand better.

## Rank what survives

Sort every real finding by **likelihood × severity × cost-to-fix-later**. A defect that is likely, damaging, and expensive to unwind once shipped goes to the top. A cosmetic nit that is trivial to fix whenever goes to the bottom — or gets dropped.

Scale your review depth to `max(change size, surface sensitivity)`. A large change earns a deep read on size alone. But a **two-line change to a sensitive surface still gets the full lens** — small diffs to auth, payments, or data capture are where the worst defects hide precisely because they look harmless.

## Output

Produce a **ranked list of genuine issues, each paired with a concrete mitigation** — not just "this is risky," but what to do about it. For every issue, state the premise you verified so the reader can trust it.

And when something is fine, **say so plainly.** Do not pad the list to look thorough. A short, honest report — "these three are real, everything else checks out" — is more useful and more credible than a long one full of hedges.