Use devils-advocate

Adversarial review of a code change before it merges

Adversarial review of a code change before it merges — the real bugs, most consequential first, each checked against the code before it is reported, with a fix that works. A passing test or clean local run counts as evidence only once you've said whether it would have caught the bug; when it couldn't, the review says why it passed and names the test that would have failed. Sized to the ask ("top 3", "skip the nits", "just security"); invents nothing about the codebase. Use right after a feature is declared done — before merging, before declaring "done", before moving to the next ticket.

Install it

npx skilldrop-cli install devils-advocate                 # Claude Code, your user folder
npx skilldrop-cli install devils-advocate --project       # Claude Code, this repo
npx skilldrop-cli install devils-advocate --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Review this code I just wrote before I merge it"
• "Anything I might have missed in this implementation?"
• "Adversarially review this diff for edge cases and broken assumptions"
• "I just finished the feature and the tests pass — is it ready to ship?"
• "Find the bugs a staff engineer would push back on in review"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Critique this design document"
• "Convene multiple senior personas to deliberate this architecture decision"
• "Implement this ticket from its acceptance criteria"

If another skill answers instead, ask for this one by name: "use devils-advocate".

Check what you get

A good result:

• Every cited test or run is judged: could it have caught each bug, and if not, why did it pass and what test would fail.
• Every finding survives a trace through the code and the stated rules. No false positives.
• The answer to "can this merge?" comes first; findings are ordered by consequence.
• Fixes work, and are code when the change is small.
• The scope asked for is respected.
• Nothing about the codebase is invented.

See a worked example

• rate limiter review

Use something else when

• For greenfield prototype or spike code that's about to be thrown away.
• For one-line or trivial changes.
• As a substitute for human code review — it's a pre-pass.
• For evaluating the choice of approach before code exists. That's a design conversation: design-doc, then doc-critique.
• For code in a language you can't reason about line by line. Refuse rather than fabricate findings.

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: design-doc, doc-critique

Edit this page on GitHub · View source