Adversarial Reviewer
Run a hostile, persona-driven review on recent diffs when normal self-review feels too agreeable before you merge.
Overview
Adversarial Reviewer is an agent skill most often used in Ship (also Build, Operate) that runs three hostile reviewer personas to produce severity-classified pre-merge verdicts.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill adversarial-reviewerWhat is this skill?
- Three adversarial personas: Saboteur, New Hire, and Security Auditor (OWASP-informed)
- Mandatory findings — each persona must surface at least one issue (no rubber-stamp LGTM)
- Severity promotion when two or more personas agree on the same issue
- Structured verdicts: BLOCK, CONCERNS, or CLEAN with merge guidance
- Self-review trap breaker techniques for shared author–reviewer mental models
- 3 adversarial reviewer personas with mandatory findings each
- Verdict types: BLOCK, CONCERNS, CLEAN
Adoption & trust: 550 installs on skills.sh; 17.5k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are reviewing your own code with the same agent that wrote it, so obvious risks get rubber-stamped as LGTM.
Who is it for?
Solo developers shipping PRs who want structured adversarial critique without installing another SaaS review bot.
Skip if: Teams that need automated patch application, formal compliance sign-off, or review of non-code artifacts only.
When should I use this skill?
You want a genuinely critical review of recent changes, before merging a PR, or when you suspect the agent is being too agreeable about code quality.
What do I get? / Deliverables
You receive mandatory findings from three personas, promoted severities where they agree, and a clear BLOCK, CONCERNS, or CLEAN merge recommendation.
- Severity-classified findings per persona with cross-promotion notes
- Structured merge verdict: BLOCK, CONCERNS, or CLEAN
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship → review is the canonical shelf because the skill targets pre-merge scrutiny with BLOCK / CONCERNS / CLEAN verdicts. Subphase review matches adversarial personas, mandatory findings, and merge guidance rather than feature implementation.
Where it fits
Run /adversarial-review on staged changes right before opening a PR to your main branch.
Stress-test a new API handler for maintainability and injection paths before you wire the frontend.
Critique a production hotfix diff for ways it could fail under load or confuse the next maintainer.
How it compares
Use instead of a single polite code-review pass when you need forced disagreement and severity promotion, not instead of CI test gates.
Common Questions / FAQ
Who is adversarial-reviewer for?
Solo and indie builders who merge their own work and want a prompt-only adversarial review when they distrust agreeable AI feedback.
When should I use adversarial-reviewer?
Use it in Ship before merging a PR, after significant staged changes, or in Build when a feature branch is feature-complete; also in Operate when reviewing hotfix diffs under time pressure.
Is adversarial-reviewer safe to install?
It is prompt-only with no shell or network requirements, but it may surface sensitive code context in chat—review the Security Audits panel on this page and avoid pasting secrets into review prompts.
SKILL.md
READMESKILL.md - Adversarial Reviewer
# Adversarial Code Reviewer ## Description Adversarial code review skill that forces genuine perspective shifts through three hostile reviewer personas (Saboteur, New Hire, Security Auditor). Each persona MUST find at least one issue — no "LGTM" escapes. Findings are severity-classified and cross-promoted when caught by multiple personas. ## Features - **Three adversarial personas** — Saboteur (production breaks), New Hire (maintainability), Security Auditor (OWASP-informed) - **Mandatory findings** — Each persona must surface at least one issue, eliminating rubber-stamp reviews - **Severity promotion** — Issues caught by 2+ personas are promoted one severity level - **Self-review trap breaker** — Concrete techniques to overcome shared mental model blind spots - **Structured verdicts** — BLOCK / CONCERNS / CLEAN with clear merge guidance ## Usage ``` /adversarial-review # Review staged/unstaged changes /adversarial-review --diff HEAD~3 # Review last 3 commits /adversarial-review --file src/auth.ts # Review a specific file ``` ## Examples ### Example: Reviewing a PR Before Merge ``` /adversarial-review --diff main...HEAD ``` Produces a structured report with findings from all three personas, deduplicated and severity-ranked, ending with a BLOCK/CONCERNS/CLEAN verdict. ## Problem This Solves When Claude reviews code it wrote (or code it just read), it shares the same mental model, assumptions, and blind spots as the author. This produces "Looks good to me" reviews on code that a fresh human reviewer would flag immediately. Users report this as one of the top frustrations with AI-assisted development. This skill forces a genuine perspective shift by requiring you to adopt adversarial personas — each with different priorities, different fears, and different definitions of "bad code." ## Table of Contents 1. [Quick Start](#quick-start) 2. [Review Workflow](#review-workflow) 3. [The Three Personas](#the-three-personas) 4. [Severity Classification](#severity-classification) 5. [Output Format](#output-format) 6. [Anti-Patterns](#anti-patterns) 7. [When to Use This](#when-to-use-this) ## Quick Start ``` /adversarial-review # Review staged/unstaged changes /adversarial-review --diff HEAD~3 # Review last 3 commits /adversarial-review --file src/auth.ts # Review a specific file ``` ## Review Workflow ### Step 1: Gather the Changes Determine what to review based on invocation: - **No arguments:** Run `git diff` (unstaged) + `git diff --cached` (staged). If both empty, run `git diff HEAD~1` (last commit). - **`--diff <ref>`:** Run `git diff <ref>`. - **`--file <path>`:** Read the entire file. Focus review on the full file rather than just changes. If no changes are found, stop and report: "Nothing to review." ### Step 2: Read the Full Context For every file in the diff: 1. Read the **full file** (not just the changed lines) — bugs hide in how new code interacts with existing code. 2. Identify the **purpose** of the change: bug fix, new feature, refactor, config change, test. 3. Note any **project conventions** from CLAUDE.md, .editorconfig, linting configs, or existing patterns. ### Step 3: Run All Three Personas Execute each persona sequentially. Each persona MUST produce at least one finding. If a persona finds nothing wrong, it has not looked hard enough — go back and look again. **IMPORTANT:** Do not soften findi