adversarial-review

Those arguments must never reach a shell

$ARGUMENTS is substituted into this file as text, so a shell receiving it would evaluate whatever it contains — $(…), backticks, ;, |. Measured on the job commands: $(echo INJECTED) was executed before Node ever started.

Read the argument text, then assemble the command from fixed pieces only. Never place the argument text, or any fragment of it, into a command, and never pass it as a single quoted string. Every value below must be one you checked against its list and then wrote out yourself — chosen, never copied:

• --base <ref>: only if it matches ^[A-Za-z0-9._/~^-]+$
• --scope <value>: auto, working-tree, branch
• --engine <value>: auto, gemini, agy
• --model <value>: an alias (flash, pro, lite, …) or an id matching ^[A-Za-z0-9][A-Za-z0-9._-]*$
• --effort <value>: none, minimal, low, medium, high, xhigh
• --engines <value>: gemini,agy or agy,gemini — nothing else is a valid pair
• --timeout <seconds>: only if it is entirely digits and between 30 and 3600
• --deep, --wait, --background, --json: literal flags, no value Any remaining text is the review focus. It is free text, so there is no safe way to quote it into a command line: use the Write tool to put it in a file and pass --focus-file <that path>. Build the path yourself; never from the user's text.

If a value is not in its set, stop and say so rather than passing it through to find out.

Run an adversarial Gemini review through the shared plugin runtime. Position it as a challenge review that questions the chosen implementation, design choices, tradeoffs, and assumptions. It is not just a stricter pass over implementation defects.

Raw slash-command arguments: $ARGUMENTS

Core constraint:

• This command is review-only.
• Do not fix issues, apply patches, or suggest that you are about to make changes.
• Your only job is to run the review and return Gemini's output verbatim to the user.
• Keep the framing focused on whether the current approach is the right one, what assumptions it depends on, and where the design could fail under real-world conditions.

Execution mode rules:

• If the raw arguments include --engines, do not ask. Run the companion in the foreground with those arguments; the runtime queues the grouped jobs in the background and returns the group ID immediately.
• If the raw arguments include --wait, do not ask. Run in the foreground.
• If the raw arguments include --background, do not ask. Run in a Claude background task.
• 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 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 use AskUserQuestion exactly once with two options, putting the recommended option first and suffixing its label with (Recommended):
  • Wait for results
  • Run in background

Argument handling:

• Preserve the user's arguments exactly.
• Do not strip --wait or --background yourself.
• Do not weaken the adversarial framing or rewrite the user's focus text.
• The companion script handles --background itself: it enqueues the review and spawns a detached review-worker, so the result outlives the foreground command. It does not outlive the session: SessionEnd removes this session's job records, finished ones included, so collect it with /gemini:result before the session ends. Do not use Claude's run_in_background: true for it.
• /gemini:adversarial-review uses the same review target selection as /gemini:review (including --base <ref> and --scope).
• Unlike /gemini:review, it can take extra focus text after the flags.
• --engines gemini,agy queues the same blind prompt on both available engines as a background group. The jobs share a group ID but do not receive each other's identity or output. Do not combine --engines with --engine or --wait.
• If one requested engine is unavailable, the runtime prints a degradation warning to stderr and queues the remaining engine as a normal single job. If neither is available, it fails without creating a job.
• --timeout <seconds> is not only how long the run may take: it is also a ceiling on how much output can be produced, because a turn that cannot finish emitting inside the window is killed. Raise it for a large scope or a batch; both engines default to 600 seconds.
• --deep runs an agentic review: Gemini uses its read-only tools to inspect repo context beyond the diff (dependency manifests, untracked files, callers) before producing the same JSON findings. Slower and higher-token; omit it for the fast, diff-scoped default. Pair --deep with --background for larger changes.