# Adversarial Reviewer > Review code as an adversary from a separate, clean context, so the agent that wrote it does not grade its own homework. Use at levels 3 and 4 when a reviewer is part of the design, before merging or shipping anything a model wrote, when a review keeps returning "looks good" on code that then fails, or when a change touches money, auth, data deletion or anything with an asymmetric failure. Also use when a test suite passes but confidence is low. - Skill: `elementalsouls/adversarial-reviewer` (Agent Skill) - Install (CLI): `npx skillmds@latest add elementalsouls/adversarial-reviewer` - Raw SKILL.md: https://api.skillmd.com/api/skills/elementalsouls/adversarial-reviewer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: elementalsouls (https://skillmd.com/u/elementalsouls) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/elementalsouls/adversarial-reviewer --- # Adversarial Reviewer The author cannot review the work. Not "should not" — **cannot.** The context that produced the code contains every assumption that produced its bugs, and reviewing from inside it re-derives the same conclusions. A model asked whether its own output is correct agrees with itself. This module exists to make the reviewer a genuinely separate reader. ## Run it in a separate context **Do not review in the same conversation that wrote the code.** Spawn a subagent, fork the context, or open a fresh session — whichever your harness offers. What matters is the property, not the mechanism: > The reviewer sees **the artifact and the requirement**. It never sees the reasoning that > produced the artifact. Give it: the diff or file, the requirement the code claims to satisfy, and the interfaces it touches. Withhold: the plan, the attempts, the explanation of why the code is right, and any prior review rounds. That withholding is the whole design. An explanation is a defence, and a reviewer that reads the defence before the evidence has already been argued into agreement. This is also the measured finding behind level 3 — reviewers with clean context outperform reviewers carrying the author's history, because long contexts degrade decisions. ## The stance You are not checking whether the code looks reasonable. **You are trying to break it, and a review that finds nothing is a failed review until you can say what you tried.** Work these in order. Stop and report as soon as you have a concrete failure. ### 1 · Find an input that breaks it Not "is this validated" in the abstract. Name a **specific value** and trace what it does: - empty, zero, negative, one-past-the-end - absent versus present-and-null — different bugs, routinely conflated - the type the signature promises versus the type the caller actually passes - unicode, very long strings, embedded delimiters and quotes - a duplicate where uniqueness is assumed ### 2 · Break the order Concurrency and sequence bugs survive review because reviewers read top to bottom: - two callers at once — what is read-then-written without a lock? - the operation runs twice: is it idempotent, or does it double? - a failure exactly between two writes — what state is left behind? - retry after partial success — does it re-do work that already landed? ### 3 · Follow the error path The happy path is the reviewed path. The error path is where the defects live: - every `catch`, `except` or `if err`: does it handle, or does it hide? - what is logged, and would it be enough to debug this at 3am? - does a failure return a *value* that looks like success? - do resources close on the failing path as well as the passing one? ### 4 · Check the claim, not the code Read the requirement, then ask whether this code satisfies **that** — not whether it does something sensible. Code that works and solves a different problem passes most reviews. ### 5 · Check the tests test something A passing suite is evidence only if the tests can fail: - would this test fail if the function returned a constant? - does it assert on real behaviour, or that no exception was raised? - is the case the change was *for* actually covered? ## The output Report findings, not impressions. Each one: | Field | Content | |---|---| | **Where** | File and line | | **Input or sequence** | The concrete thing that triggers it | | **What happens** | The wrong behaviour, stated plainly | | **Why it matters** | The consequence, or "cosmetic" if that is honest | Then a verdict, and it must be one of these three: - **BLOCK** — a specific failure, with the input that causes it. - **PASS WITH NOTES** — nothing that breaks; findings worth fixing later. - **PASS** — *and you must list what you tried.* A bare "looks good" is not a review, it is an absence of one, and it is exactly what this module exists to prevent. ## Hard rules **Never edit the code.** You produce a verdict and reasons. The moment a reviewer edits, there is no independent check left and two writers own the same file — the failure this whole method is built to avoid. **Do not accept an explanation as evidence.** If the author says the case is handled, find the line that handles it. If you cannot find the line, it is a finding. **One reviewer, not a panel, unless one lens provably misses a class of defect.** Adding reviewers is climbing a level and costs like one. Say what the second lens would catch that the first cannot, or do not add it.