# 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 us… - **Type:** Skill - **Install:** `agentstack add skill-elementalsouls-orchestration-design-adversarial-reviewer` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [elementalsouls](https://agentstack.voostack.com/s/elementalsouls) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [elementalsouls](https://github.com/elementalsouls) - **Source:** https://github.com/elementalsouls/orchestration-design/tree/main/skill/orchestration-design/modules/adversarial-reviewer ## Install ```sh agentstack add skill-elementalsouls-orchestration-design-adversarial-reviewer ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [elementalsouls](https://github.com/elementalsouls) - **Source:** [elementalsouls/orchestration-design](https://github.com/elementalsouls/orchestration-design) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-elementalsouls-orchestration-design-adversarial-reviewer - Seller: https://agentstack.voostack.com/s/elementalsouls - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.