skills/community/adversarial-review/SKILL.md
Adversarial code review using the opposite model. Spawns 1–3 reviewers on the opposing model (Claude spawns Codex, Codex spawns Claude) to challenge work from distinct critical lenses. Triggers: "adversarial review".
npx skillsauth add pedronauck/skills adversarial-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
Read brain/principles.md. Follow every [[wikilink]] and read each linked principle file.
These govern reviewer judgments.
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.
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.
Each reviewer gets a single prompt containing:
Spawn all reviewers in parallel.
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:
## Intent
<what the author is trying to achieve>
## Verdict: PASS | CONTESTED | REJECT
<one-line summary>
## Findings
<numbered list, ordered by severity (high → medium → low)>
For each finding:
- **[severity]** Description with file:line references
- Lens: which reviewer raised it
- Principle: which brain principle it maps to
- Recommendation: concrete action, not vague advice
## What Went Well
<1–3 things the reviewers found no issue with — acknowledge good work>
Verdict logic:
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 to the verdict:
## Lead Judgment
<for each finding: accept or reject with a one-line rationale>
development
Deep review of branch diffs, working trees, or GitHub PRs at any size. Use when the user asks for CodeRabbit-grade review, an incremental re-review after new pushes, publication of findings to a PR, a cross-LLM peer-review verdict round, or conformance review against spec artifacts. Don't use for applying fixes, reviewing specs or PRDs as documents, or quick single-file feedback.
tools
Orchestrate Claude and Codex worker TUIs from a controller agent through herdr panes and the herdr socket CLI. Use when delegating bounded tasks to herdr worker panes, running user-activated plan-first delegations (Claude Code plan mode, Codex Plan mode), waiting on native agent status (idle, working, blocked, done), or verifying worker reports. Workers launch as interactive TUIs via herdr agent start — never through headless runners (compozy exec, claude -p, codex exec). Not for cmux workspaces (see cmux-orchestration) and not for end-user herdr control.
tools
TanStack Query, Router, and Form patterns for React. Use when writing useQuery/queryOptions, mutations, caching, file-based routes, search params, loaders, or TanStack Form validation. Don't use for TanStack Start, TanStack DB/collections, Zustand client state, or non-TanStack routing.
development
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.