skills/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>
tools
Plans real-user QA deliverables: personas, journey maps, exploratory charters, persona/journey/tour/CFR test cases, regression suites, Figma validation checks, automation intent, and user-impact bug reports. Writes artifacts under <qa-output-path>/qa/ for qa-execution to consume. Use when planning QA before execution, documenting journey-driven test strategy, marking flows that need E2E follow-up, or filing structured bug reports. Do not use for live execution, AI implementation audits, CI gate ownership, or technical integration/security/performance suites; use qa-execution or agent-output-audit instead.
development
Executes real-user QA sessions through public interfaces using personas, journeys, exploratory charters, test tours, edge-case probes, CFR checks, and browser evidence. Reads qa-report artifacts from <qa-output-path>/qa/ when present, captures issues/screenshots/reports under the same output tree, and classifies bugs by user impact. Use when validating a release candidate, migration, refactor, or user-facing change against production-like behavior. Do not use for AI implementation audits, task-status reconciliation, CI gate runs, integration/security/performance templates, or flaky-test triage; use agent-output-audit for those.
development
Transform outside-of-diff review files into properly formatted issue files for a given PR. Use when converting review files from ai-docs/reviews-pr-<PR>/outside/ into issue format in ai-docs/reviews-pr-<PR>/issues/. Automatically determines starting issue number and preserves all metadata (file path, date, status) from original review files. Don't use for inline-diff review files, non-PR review artifacts, or creating GitHub issues directly.
development
Enforce root-cause fixes over workarounds, hacks, and symptom patches in all software engineering tasks. Use when debugging issues, fixing bugs, resolving test failures, planning solutions, making architectural decisions, or reviewing code changes. Activates gate functions that detect and reject common workaround patterns such as type assertions, lint suppressions, error swallowing, timing hacks, and monkey patches. Don't use for trivial formatting changes or documentation-only edits.