Claude's harshest critic. A Claude Code plugin that critiques Claude's work with binary pass/fail evaluation — every criterion either passes or fails, no percentage scores, no wiggle room.
Claude writes code confidently. Too confidently. Left unchecked, it'll tell you everything looks wonderful right up until production catches fire. Inspired by Confidently Wrong.
A devil's advocate argues against a position not because they believe the other side, but to surface the holes everyone else missed. This plugin gives Claude that role — the skeptical colleague who says "yeah, but what about..." instead of "LGTM."
Every criterion demands file:line evidence and a fix suggestion — no hand-waving, no vibes-based reviews.
It'll flag you for reinventing bcrypt, missing authorization checks, duplicating a helper that already exists three directories away, writing plans where step 4 depends on step 7, N+1 queries in hot paths, and shipping without a rollback strategy. It knows when you're hand-rolling auth instead of using a battle-tested library, and it won't let you forget that "works on my machine" isn't a testing strategy.
It also catches architectural drift — when Claude bypasses an established API layer to hit a database directly, adds special-case conditionals instead of proper abstractions, or papers over a root cause with a band-aid fix. It mines your codebase for dominant patterns and enforces them, even if they're not documented.
And it's honest in both directions: when everything genuinely passes, the verdict is READY TO SHIP (code) or APPROVED (plans) — it's forbidden from manufacturing problems to appear thorough. "Do nothing" is a valid outcome.
It works on both code and plans — auto-detecting which criteria set to use based on what you're reviewing.
/plugin marketplace add brandonsimpson/devils-advocate
/plugin install devils-advocate@devils-advocate
Manual install
git clone https://github.com/brandonsimpson/devils-advocate.gitSingle session — note the /plugin suffix; the plugin lives in the plugin/ subdirectory, not the repo root:
claude --plugin-dir ./devils-advocate/pluginPermanent — link the plugin into your skills directory and it loads every session as devils-advocate@skills-dir:
ln -s "$(pwd)/devils-advocate/plugin" ~/.claude/skills/devils-advocate| Slash command | Natural language |
|---|---|
/devils-advocate:critique |
"critique" or "critique this plan" |
/devils-advocate:log |
"show critique log" |
Binary pass/fail critique across every dimension that matters. Auto-detects whether you're reviewing code or a plan document.
Independence gate: When critiquing work Claude wrote in the same conversation, it automatically dispatches an independent subagent to avoid author bias — the reviewer never sees the author's reasoning, only the artifact and codebase.
Code critique (20 criteria, 7 dimensions):
- Correctness — Tests pass? Logic correct? Edge cases handled?
- Security — No hardcoded secrets, input validated, no injection vectors, auth enforced?
- Quality — No dead code, no placeholders, errors handled properly, no code smell?
- Performance — No N+1 queries, no O(n^2) in hot paths?
- Consistency — Types match, naming follows conventions, patterns followed?
- Integration — Imports resolve, tests exist, no regressions?
- Architecture — Established boundaries respected, no hacky shortcuts?
Plan critique (22 criteria, 10 dimensions):
- Completeness — Requirements covered, no placeholders, edge cases addressed?
- Correctness — APIs verified against docs, patterns match library usage?
- Testability — Specific tests per step, E2E verification strategy?
- Security — Secrets managed properly, input validated, auth designed?
- Consistency — Types consistent, naming follows conventions?
- Simplicity — No overengineering, no reinventing solved problems?
- Dependencies — Correct task ordering, all deps available?
- Resilience — Rollback plan exists, performance considered?
- Integration — Import paths valid, follows project patterns?
- Architecture — Established boundaries respected, no hacky shortcuts?
Every FAIL comes with a Fix: suggestion. Example output:
DEVIL'S ADVOCATE CRITIQUE (Binary Eval)
═══════════════════════════════════════
Target: code changes for webhook handler
Correctness:
tests-pass ...... PASS
logic-correct ... PASS
edge-cases ...... FAIL — No handling for empty payload at webhook.ts:45.
Fix: Add early return with 400 status for empty/malformed payloads.
Security:
no-secrets ...... PASS
input-validated . FAIL — String interpolation in buildQuery() at db.ts:23.
Fix: Use parameterized query builder.
no-injection .... FAIL — innerHTML used at dashboard.tsx:89.
Fix: Use textContent or a sanitization library.
auth-enforced ... PASS
...
Result: 15/20 PASS — 5 criteria need fixing
Failing criteria with fixes:
1. edge-cases: Add early return for empty payloads at webhook.ts:45
2. input-validated: Use parameterized queries at db.ts:23
3. no-injection: Replace innerHTML at dashboard.tsx:89
4. ...
When everything passes, it says so plainly instead of inventing nits:
Result: 20/20 PASS
VERDICT: READY TO SHIP — No blockers. All 20 criteria pass. This work is clean.
Unverified:
• Did not test against the live payment API — recorded fixtures only
Every critique ends with an Unverified section — at least one thing it did not check. A reviewer that claims it verified everything is lying.
When criteria fail, the critique offers to fix them and re-run. Each critique authorizes exactly one commit, so the cycle closes itself: fix → re-critique → commit.
Session history — total checks, pass rate trend, and git SHA linking each check to a specific commit. Individual critiques are saved to .devils-advocate/logs/ for later reference.
The critique skill automatically discovers your project's documented standards before evaluating:
CLAUDE.md/AGENTS.md— Your conventions, required patterns, and constraints. Standards violations cause relevant criteria to FAIL.- ADR files — Searched in
docs/adr/,docs/decisions/,adr/,decisions/,doc/architecture/decisions/, and**/ADR-*.md - Existing patterns — Utilities, helpers, and conventions already in your codebase that the critiqued code might be duplicating.
- Architectural boundaries — Barrel exports, API client modules, repository patterns, and service layers that indicate intentional boundaries. If 5+ instances in your codebase do something one way, that's the established pattern — violations fail even if undocumented.
Every check is logged to .devils-advocate/session.md with a git SHA, so you can correlate results with specific commits. Full critique output is saved to individual files in .devils-advocate/logs/. Add .devils-advocate/ to your .gitignore.
A pre-commit hook nudges you to run a critique before committing — the commit still proceeds, it's just a reminder. A plan-file hook suggests running /devils-advocate:critique when you write a plan file. Both hooks are configurable via .devils-advocate/config.json:
{"hooks": {"pre-commit-warning": false, "plan-file-detect": false}}The critic gets criticized too. The plugin ships with 169 deterministic checks (metadata, criteria completeness, hook behavior, output format) plus 6 live-LLM evals that feed planted-bug fixtures through the critique skill and assert it catches them — without manufacturing failures on clean work. On the eval suite's first run, it failed its own "clean" fixture; the model had found three real flaws in it. The fixtures got fixed, not the thresholds.
Release history: CHANGELOG.md
MIT