/adversarial-review

name: adversarial-review
description: 'Run a design-challenging Claude Code review of local git changes in this repository. Args: --wait, --background, --base <ref>, --scope <auto|working-tree|branch>, --model <model>, --effort <low|medium|high|xhigh|max>, [focus text]. Defaults to opus with no forced effort. Use only when the user wants stronger scrutiny than a normal review, such as explicit tradeoff challenge, risky-change review, or custom focus text.'

Claude Code Adversarial Review

Use this skill when the user wants Claude Code to challenge the implementation approach, design choices, assumptions, or tradeoffs in this repository.

Do not treat `$cc:adversarial-review` as the default review path. Use it only when the user explicitly wants stronger scrutiny than a normal code review. Good triggers include requests to challenge the design, challenge tradeoffs, pressure-test a risky change, question whether a migration/config/template change really removed the risk, or honor custom focus text that asks for harsher review. If the user wants Claude Code to go beyond review and perform investigation, validation edits, or implementation work, route to `$cc:rescue` instead. If the user asks for a local review plus a separate Claude background review and then wants the main Codex thread to aggregate the findings and apply fixes, keep the delegated Claude portion on `$cc:review` unless the user explicitly asks for the adversarial angle. Unlike `$cc:review`, this skill accepts custom focus text after the flags. The moment the user wants to steer Claude toward a specific angle or risk question, prefer `$cc:adversarial-review`.

Resolve `<plugin-root>` as two directories above this `SKILL.md` file. Always run the companion from that active plugin root: `node "<plugin-root>/scripts/claude-companion.mjs" adversarial-review ...`

Supported arguments: `--wait`, `--background`, `--base <ref>`, `--scope auto|working-tree|branch`, `--model <model>`, `--effort <low|medium|high|xhigh|max>`, plus optional focus text after the flags (defaults: model=opus and no effort; `fable`, `opus`, `sonnet`, and `haiku` each keep Claude Code's own effort default, and Claude Code owns which effort levels each model supports)

Forward `--model` unchanged to the companion. The companion trims surrounding whitespace, canonicalizes the friendly aliases `fable`, `opus`, `sonnet`, and `haiku` to lowercase, then forwards every other `--model` value unchanged to Claude Code. Claude Code owns alias resolution and supported effort levels; `/model` is the authoritative picker for the current account and provider.

Raw slash-command arguments: `$ARGUMENTS`

Rules:

• This skill is review-only. Do not fix issues, apply patches, or suggest that you are about to make changes.
• Before launching the review, stay in read-only inspection mode: inspect git status and diff stats only, then ask at most one user question about whether to wait or run in background.
• Preserve the user's scope flags and custom focus text exactly.
• Use the same review target selection as `$cc:review`.

Execution mode rules:

• If the raw arguments include `--wait`, do not ask. Run in the foreground.
• If the raw arguments include `--background`, do not ask. Run in background through the built-in adversarial-review subagent path.
• Otherwise, estimate the review size before asking:
• For working-tree review, start with `git status --short --untracked-files=all`.
• For working-tree review, also inspect both `git diff --shortstat --cached` and `git diff --shortstat`.
• For base-branch review, use `git diff --shortstat <base>...HEAD`.
• Treat untracked files or directories as reviewable work for auto or working-tree review even when `git diff --shortstat` is empty.
• Only conclude there is nothing to review when the relevant scope is actually empty.
• Recommend waiting only when the scoped review is clearly tiny, roughly 1-2 files total and no sign of a broader directory-sized change.
• In every other case, including unclear size, recommend background.
• When in doubt, run the review instead of declaring that there is nothing to review.
• Then ask the user once which execution mode to use, offering two options with the recommended one first and its label suffixed `(Recommended)`:
• `Wait for results`
• `Run in background`
• Use a question tool for that ask only when this thread actually has one. Codex exposes `request_user_input` only behind `[tools] experimental_request_user_input`, and it does not exist in non-interactive threads. If you have no question tool but a user is reading this thread, ask in your own reply and stop there. In a non-interactive thread with no user to answer, skip the ask and proceed with the recommended mode. Never spin on a wait or collaboration tool looking for a picker this thread does not have.

Argument handling:

• Preserve the user's arguments exactly.
• Treat `--wait` and `--background` as Codex-side execution controls only. Strip them before calling the companion command.
• Do not weaken the adversarial framing or rewrite the user's focus text.
• `$cc:adversarial-review` uses the same review target selection as `$cc:review`.
• It supports working-tree review, branch review, and `--base <ref>`.
• It does not support `--scope staged` or `--scope unstaged`.
• Unlike `$cc:review`, it can still take extra focus text after the flags.
• The companion review process itself always runs in the foreground. Background mode only changes how Codex launches that command.
• For the detailed execution contract, treat the internal runtime reference at `../../internal-skills/review-runtime/runtime.md` as supporting guidance only. It is an internal reference document, not a public skill to invoke.

Foreground flow:

• Run:

`node "<plugin-root>/scripts/claude-companion.mjs" adversarial-review --view-state on-success <arguments with --wait/--background removed>`

• Run that companion command with `sandbox_permissions: "requ