adversarial-review
poteto/noodle
Cross-model adversarial code review that spawns opposing AI reviewers to challenge work from distinct critical lenses.
What is adversarial-review?
Adversarial Review spawns reviewers on the opposite model (Claude uses Codex, Codex uses Claude) to challenge code changes from multiple critical perspectives. Use it after large diffs, implementation phases, or planning sessions to get synthesized findings and a lead judgment without making automatic changes.
- Spawns reviewers on the opposite model to avoid same-model bias
- Applies distinct reviewer lenses (Skeptic, Architect, Minimalist) based on change size
- Deduplicates overlapping findings across reviewers
- Produces a synthesized verdict with findings and lead judgment
- Requires explicit intent statement before review begins
How to install adversarial-review
npx skills add https://github.com/poteto/noodle --skill adversarial-review- Access to opposite model CLI (codex exec if Claude; claude CLI if Codex)
- brain/principles.md and linked principle files in project
- references/reviewer-lenses.md for lens definitions
- references/reviewer-prompt.md for prompt template
- references/verdict-format.md for output format
How to use adversarial-review
- 1.Read brain/principles.md and follow all [[wikilink]] references to understand reviewer judgment framework
- 2.Identify the scope and intent of the code to review from recent diffs or context
- 3.Determine change size (Small <50 lines, Medium 50-200 lines, Large 200+ lines) to select reviewer count
- 4.Create temp directory and spawn reviewers on opposite model using appropriate CLI (codex exec or claude -p)
- 5.Verify reviewer output files exist and read each reviewer's findings
- 6.Deduplicate overlapping findings and synthesize into single verdict using verdict-format.md template
- 7.Apply your own judgment to accept or reject findings based on stated intent and brain principles
- 8.Append Lead Judgment section explaining which findings warrant action and why
Use cases
- Review large diffs (200+ lines) before merging to catch cross-model blind spots
- Challenge implementation plans after completion to surface architectural concerns
- Validate planning sessions with adversarial perspective from opposing model
- Audit code changes for consistency with stated brain principles
- Identify false positives and style-vs-substance issues in reviewer findings
- Coding agents using Claude or Codex CLI
- Teams practicing adversarial code review
- Projects with large or complex diffs requiring multi-lens critique
- Developers who want to avoid same-model confirmation bias
adversarial-review FAQ
Running reviewers on your own model defeats the purpose—they would share your model's biases and blind spots. Opposite-model reviewers provide genuinely adversarial perspective from a different architecture and training.
Trigger after large diffs (200+ lines), implementation plan phases, or planning sessions. Small changes (<50 lines) need only one Skeptic reviewer; medium changes need Skeptic + Architect; large changes need all three lenses.
Note the failure explicitly in the verdict—do not silently skip a reviewer. This indicates a problem that should be logged and investigated.
No. The deliverable is a synthesized verdict with findings and judgment. You apply your own judgment to decide which findings warrant action, based on stated intent and brain principles.
Identify what the author is trying to achieve from context (recent diffs, referenced plans, user message). State the intent explicitly before proceeding—reviewers challenge whether the work achieves the intent well, not whether the intent itself is correct.
Full instructions (SKILL.md)
Source of truth, from poteto/noodle.
name: adversarial-review description: >- Adversarial code review using cross-model approach. Spawns reviewers on the opposing model (Claude uses Codex, Codex uses Claude) to challenge work from distinct critical lenses. Produces a synthesized verdict with findings and lead judgment. Triggers: "adversarial review". schedule: "After cook sessions that produce large diffs (200+ lines), implement plan phases, or complete a planning session"
Adversarial Review
Spawn reviewers on the opposite model to challenge work. Reviewers attack from distinct lenses grounded in brain principles. The deliverable is a synthesized verdict — do NOT make changes.
Hard constraint: Reviewers MUST run via the opposite model's CLI (codex exec or
claude -p). Do NOT use subagents, the Agent tool, or any internal delegation mechanism as
reviewers — those run on your own model, which defeats the purpose.
Step 1 — Load Principles
Read brain/principles.md. Follow every [[wikilink]] and read each linked principle file.
These govern reviewer judgments.
Step 2 — Determine Scope and Intent
Identify what to review from context (recent diffs, referenced plans, user message).
Determine the intent — what the author is trying to achieve. This is critical: reviewers challenge whether the work achieves the intent well, not whether the intent is correct. State the intent explicitly before proceeding.
Assess change size:
| Size | Threshold | Reviewers |
|---|---|---|
| Small | < 50 lines, 1-2 files | 1 (Skeptic) |
| Medium | 50-200 lines, 3-5 files | 2 (Skeptic + Architect) |
| Large | 200+ lines or 5+ files | 3 (Skeptic + Architect + Minimalist) |
Read references/reviewer-lenses.md for lens definitions.
Step 3 — Detect Model and Spawn Reviewers
Create a temp directory for reviewer output:
REVIEW_DIR=$(mktemp -d /tmp/adversarial-review.XXXXXX)
Determine which model you are, then spawn reviewers on the opposite:
If you are Claude — spawn Codex reviewers via codex exec:
codex exec --skip-git-repo-check -o "$REVIEW_DIR/skeptic.md" "prompt" 2>/dev/null
Use --profile edit only if the reviewer needs to run tests. Default to read-only.
Run with run_in_background: true, monitor via TaskOutput with block: true, timeout: 600000.
If you are Codex — spawn Claude reviewers via claude CLI:
claude -p "prompt" > "$REVIEW_DIR/skeptic.md" 2>/dev/null
Run with run_in_background: true.
Name each output file after the lens: skeptic.md, architect.md, minimalist.md.
Build each reviewer's prompt using the template in references/reviewer-prompt.md.
Step 4 — Verify and Synthesize Verdict
Before reading reviewer output, log which CLI was used and confirm the output files exist:
echo "reviewer_cli=codex|claude"
ls "$REVIEW_DIR"/*.md
If any output file is missing or empty, note the failure in the verdict — do not silently skip a reviewer.
Read each reviewer's output file from $REVIEW_DIR/. Deduplicate overlapping findings.
Produce a single verdict using the format in references/verdict-format.md.
Step 5 — Render Judgment
After synthesizing the reviewers, apply your own judgment. Using the stated intent and brain principles as your frame, state which findings you would accept and which you would reject — and why. Reviewers are adversarial by design; not every finding warrants action. Call out false positives, overreach, and findings that mistake style for substance.
Append the Lead Judgment section to the verdict (see references/verdict-format.md).
Related skills
More from poteto/noodle and the wider catalog.
powersync
Guided onboarding and best practices for building applications with PowerSync — Cloud and self-hosted setup, sync configuration, client SDK usage, backend integration (Supabase, custom Postgres, MongoDB, MySQL, MSSQL), and debugging. Use this skill whenever the user mentions PowerSync, offline-first sync, local-first architecture, sync rules, sync streams, uploadData, fetchCredentials, real-time data replication, or wants to add offline-capable sync to a mobile or web app — even if they don't explicitly name PowerSync.
chrome-extension
Chrome Extensions (Manifest V3) performance and code quality guidelines. Use when writing, reviewing, or refactoring Chrome extension code including service workers, content scripts, message passing, storage APIs, TypeScript patterns, and testing.
clean-architecture
Clean Architecture principles and best practices for designing maintainable, testable software systems.
clean-code
Use when writing, reviewing, or refactoring code for maintainability and readability. Triggers on code reviews, naming discussions, function design, error handling, and test writing. Based on Robert C. Martin's Clean Code handbook with modern corrections.
code-simplifier
Simplify code while preserving behavior using 47 prioritized best-practice rules.
emilkowal-animations
Emil Kowalski's animation best practices for React, CSS, and Framer Motion.