--- name: code-review description: >- Code review by several models at once — Claude sub-agents, OpenAI Codex, and a cheap third reviewer via OpenCode — reconciled into one report. Reviews whatever is named: a diff, a branch, specific files, one function, a legacy module, a whole repo. Use for any review request, a second or third opinion, a cross-check before a PR, or "code-review", "multi", "consensus review". allowed-tools: Bash, Read, Grep, Glob, Agent, TodoWrite argument-hint: "[what to review, in words] [lite|normal|ultra] [haiku|sonnet|opus|fable] [low|medium|high|xhigh|max]" ---

# Multi-model code review

!`sh -c 'for p in "$CLAUDE_PLUGIN_ROOT/scripts" "$HOME/.claude/skills/multi/scripts" "./.claude/skills/multi/scripts"; do [ -x "$p/probe.sh" ] && { "$p/probe.sh"; echo "scripts-dir: $p"; exit 0; }; done; echo "probe: NOT FOUND — locate scripts/probe.sh in this plugin and run it yourself"'`

Several models read the same code, and you decide what reaches the user. That is the whole idea: one model invents problems and walks past real ones, and you cannot tell which from a single report. Independent models disagree, and the disagreement is the signal.

You are the judge, not a dispatcher. The reviewers propose; they do not vote, and none of them gets the last word. When they conflict, open the code and decide.

This is normally reached at the end of a session — work is done, PR or push comes next. Act like it: the question is "is this ready", not "here are some observations".

`$SCRIPTS` below is whatever the probe printed as `scripts-dir:`.

## The gate

From the probe lines above — they are already there, do not re-run it.

**No second reviewer family → stop.** This is multi-model review; the review pipeline can run two non-Claude families, Codex and OpenCode — without at least one of them there is nothing here that a single-model review does not already do. OpenRouter and Gemini are real second families, but this pipeline cannot run them as reviewers yet: they serve `/multi:ask`, not this skill. Say which is missing and point at `/multi:setup`. Do not quietly deliver a one-model review wearing a three-model label.

Anything else missing is a note, not a stop: no OpenCode, no ponytail, not a git repo (fine — then the target is files, not a diff). Name what was missing in the report and carry on.

Whatever is missing, point them at `/multi:setup` to connect it — it walks through this step by step and does not need them to know any of the above.

## Decide what you are reviewing

**Whatever the user named.** A diff, a branch, two files, one function, a line range, a module nobody has touched in three years, the whole repository. There is no fixed vocabulary here and no menu — read what they wrote and work out what they mean, the way a colleague would.

When nothing was named, in this order:

1. **What this session was about.** If you just wrote or changed something, that is the target — you know which files, what the task was, where you were unsure, what you fixed blind. That is better than a diff, which in a dirty tree also holds debug leftovers and unrelated edits, and which misses the old code the change leans on. 2. **The branch**, if it is ahead of main and the tree is clean. 3. **The uncommitted diff** otherwise.

Ask only when the answer genuinely changes what gets reviewed and you cannot tell — dirty tree *and* they mentioned a PR, say. Never open with a questionnaire: this skill runs at the end of a session, sometimes inside an autonomous run, and three questions there are worse than a wrong guess you announced. Guess, say what you guessed, let them correct you.

Whatever you settle on, resolve it into **concrete paths, or a concrete git range, before dispatching**. Every reviewer must look at the same thing — otherwise "two of them agreed" means nothing, they just happened to read the same file. If the target is vague, resolve it and say what you resolved it to.

## Say what you are about to do

**Always, before launching anything.** Short, then go — this is not a request for permission, and you do not wait for an answer:

``` Reviewing: <target, and where it came from — "what we just did", "branch vs main", "you asked for src/auth.py"> <when $REPO is not the session's own checkout, show the resolved path so a wrong-tree review is caught before it runs> Running now: Codex <effort> · OpenCode <model> · ponytail <— or why one is missing Then: <what decides the Claude spend> ```

If they wanted something else they will say so, and interrupting is cheaper than an interrogation.

## Launch everything free, immediately

Codex, OpenCode and the ponytail lens cost nothing per run and take 30–70 seconds wall clock. There is never a reason to hold them back or make them conditional on a mode. Start the two external ones **in the background, both at once** — OpenCode spends about a minute just warming up — and do everything else while they run.

```bash RUN="$($SCRIPTS/run-dir.sh --slug <two-to-four words: the project and the job, e.g. skills-fixing-multi>)"

# The tree under review. Usually the session's own repo; set REVIEW_DIR to a # path or a different worktree when THAT is the target. Resolve it once and hand # it to every backend: cwd resets between these blocks, so without an explicit # --repo the reviewers silently read the session checkout and can "agree" on an # empty diff. REPO="$(git -C "${REVIEW_DIR:-.}" rev-parse --show-toplevel)"

$SCRIPTS/collect-context.sh --repo "$REPO" [--diff <spec>] [--paths "<paths>"] > "$RUN/ctx.md"

$SCRIPTS/review-prompt.sh --repo "$REPO" --target "<in words>" [--diff <spec>] [--paths "<paths>"] \ [--focus "<user text>"] --context "$RUN/ctx.md" > "$RUN/review.prompt.md" $SCRIPTS/ask.sh --repo "$REPO" --question-file "$RUN/review.prompt.md" --out-prefix "$RUN/review" \ --backend "codex,opencode:<model from probe>" --fallback <from probe> \ --effort <low|medium|high|xhigh|max> --timeout "${MULTI_REVIEW_TIMEOUT:-900}" ```

`run-dir.sh` prints this session's own directory, `/tmp/multi/<session>--<slug>`, and creates it. Two sessions reviewing at once used to share fixed `/tmp` names and overwrite each other's files. Shell variables do not survive between commands, so repeat that first line — and the `REPO=` line — in every later block that needs them; `--slug` only labels the directory the first time, so a different wording later still lands in the same place. Runs older than a week are swept.

`--diff` is what makes it a *change* review; leave it off and the reviewers read the actual code instead, with old code fully in scope. `--paths` narrows hard. `--target` is always required — it is the human sentence, and it is what keeps the reviewers pointed at the same thing. `--repo` is the *directory* they work in; it defaults to cwd, so you only think about it when the target is a different worktree, but passing `$REPO` always is free and removes the guesswork.

The probe at the top of this file ran with no `--repo`, so its `repo:`, branch, dirty-file and ahead-of-main numbers describe the **session checkout**. When `$REPO` is a different worktree, those numbers are for the wrong tree — re-run `$SCRIPTS/probe.sh --repo "$REPO"` to orient on the real target before you trust them.

`collect-context.sh` gathers the repo's `CLAUDE.md`/`AGENTS.md` and the `.claude/rules/*.md` matching the target, and every reviewer gets it. This is what separates this from three models guessing: an external reviewer that does not know the project's settled decisions spends its findings re-litigating them.

**The ponytail lens** — invoke the `ponytail:ponytail-review` skill on the same target whenever the probe found it. It hunts one thing, over-engineering, and that keeps the defect reviewers out of matters of taste entirely (see below). Its findings are a different kind of thing and never mix with defects: they get their own section and cannot corroborate or contradict a bug.

> If ponytail mode is *active*, its `SubagentStart` hook injects the YAGNI > ruleset into every sub-agent, including the ones hunting bugs. If findings > start reading like simplification advice, that is why; `PONYTAIL_SUBAGENT_MATCHER` > is the fix. Mention it once, move on.

## Then decide how much Claude to spend

The external reviewers are free; your sub-agents are the user's money. So do not guess the depth up front — **wait for the free results and decide on evidence**. A two-line change both reviewers called clean does not need three sub-agents. A change where Codex reports two HIGH and OpenCode disagrees with one of them does.

Say the decision in one line when you make it: *"going to normal — Codex found two HIGH, OpenCode contradicts one."*

An explicitly named mode skips all of this. Obey it.

| | Claude sub-agents | when | |---|---|---| | `lite` | `correctness` only | small, low-risk, external reviewers agree and found little | | `normal` *(default)* | `correctness` · `security` · `design` | anything heading for a PR | | `ultra` | those three, plus `execution`, plus an adversarial second Codex pass (`--adversarial`), plus one `verify` per single-source finding | expensive to get wrong, or asked for |

The adversarial pass needs Codex specifically; without it, `ultra` runs without that pass — the rest of the mode is unchanged.

Spawn them **in parallel, in one message**. Give each the target, the paths or range, the contents of `$RUN/ctx.md`, and the user's own words if there were any. Give them `$REPO` too and say it plainly — *run git and read files in `$REPO`, not your current directory* — because a sub-agent starts in the session checkout, and if the target is another worktree it would otherwise review the wrong tree, exactly as the CLI backends would without `--repo`.

**Model**: the argument if given, else `MULTI_REVIEWER_MODEL` from the probe, else the agent files' default (Sonnet). **No mode raises it on its own** — `ultra` buys depth through more angles and real verification, not a bigger model.

**`ultra` is not a deeper code review — it reviews whether the task got done.** Was there a plan and was it followed; is the thing actually finished or only finished-looking; what was silently skipped; what will detonate later. That needs the task context — the plan, the spec, the conversation. Hand `execution` what you actually know about the job. Without any of that, `ultra` degrades to `normal` plus an architecture angle, and you should say so rather than pretend.

## Judge

Normalize everything to `{file, line, severity, claim}`. Codex and OpenCode both answer the unified review prompt as `FILE:LINE | HIGH|MEDIUM|LOW | reason`, with repo-relative paths. OpenCode's file has two parts: `## <model>` listing every tool call it made, then `## Answer` with what it wrote in that unified format. Sub-agents report `FILE:LINE | SEVERITY | confidence NN` with two lines under it.

**Read OpenCode's call list before its findings.** It is there to answer one question: did this reviewer actually look at the code it is talking about? A finding about a file that never appears in the call list was invented, and it goes in `Dropped`. `(none — this reviewer answered without opening anything)` means the whole report is guesswork. `NO ANSWER` means it ran and said nothing: that reviewer was absent, say so as `Codex/Opencode FAILED: <reason>` from the one-line text in `*.dead` rather than reading silence as agreement.

Bucket by *the underlying problem*, not by wording — the same bug gets three different descriptions:

- **Corroborated** — two or more reviewers from different families (Claude / Codex / OpenCode). Leads the report; independent agreement is the strongest evidence this pipeline produces. - **Single-source** — one reviewer. Check each before the user sees it: open the cited lines, confirm it is real and reachable. In `ultra`, spawn one `verify` per finding instead an

--- name: code-review description: >- Code review by several models at once — Claude sub-agents, OpenAI Codex, and a cheap third reviewer via OpenCode — reconciled into one report. Reviews whatever is named: a diff, a branch, specific files, one function, a legacy module, a whole repo. Use for any review request, a second or third opinion, a cross-check before a PR, or "code-review", "multi", "consensus review". allowed-tools: Bash, Read, Grep, Glob, Agent, TodoWrite argument-hint: "[what to review, in words] [lite|normal|ultra] [haiku|sonnet|opus|fable] [low|medium|high|xhigh|max]" ---

# Multi-model code review

!`sh -c 'for p in "$CLAUDE_PLUGIN_ROOT/scripts" "$HOME/.claude/skills/multi/scripts" "./.claude/skills/multi/scripts"; do [ -x "$p/probe.sh" ] && { "$p/probe.sh"; echo "scripts-dir: $p"; exit 0; }; done; echo "probe: NOT FOUND — locate scripts/probe.sh in this plugin and run it yourself"'`

Several models read the same code, and you decide what reaches the user. That is the whole idea: one model invents problems and walks past real ones, and you cannot tell which from a single report. Independent models disagree, and the disagreement is the signal.

You are the judge, not a dispatcher. The reviewers propose; they do not vote, and none of them gets the last word. When they conflict, open the code and decide.

This is normally reached at the end of a session — work is done, PR or push comes next. Act like it: the question is "is this ready", not "here are some observations".

`$SCRIPTS` below is whatever the probe printed as `scripts-dir:`.

## The gate

From the probe lines above — they are already there, do not re-run it.

**No second reviewer family → stop.** This is multi-model review; the review pipeline can run two non-Claude families, Codex and OpenCode — without at least one of them there is nothing here that a single-model review does not already do. OpenRouter and Gemini are real second families, but this pipeline cannot run them as reviewers yet: they serve `/multi:ask`, not this skill. Say which is missing and point at `/multi:setup`. Do not quietly deliver a one-model review wearing a three-model label.

Anything else missing is a note, not a stop: no OpenCode, no ponytail, not a git repo (fine — then the target is files, not a diff). Name what was missing in the report and carry on.

Whatever is missing, point them at `/multi:setup` to connect it — it walks through this step by step and does not need them to know any of the above.

## Decide what you are reviewing

**Whatever the user named.** A diff, a branch, two files, one function, a line range, a module nobody has touched in three years, the whole repository. There is no fixed vocabulary here and no menu — read what they wrote and work out what they mean, the way a colleague would.

When nothing was named, in this order:

1. **What this session was about.** If you just wrote or changed something, that is the target — you know which files, what the task was, where you were unsure, what you fixed blind. That is better than a diff, which in a dirty tree also holds debug leftovers and unrelated edits, and which misses the old code the change leans on. 2. **The branch**, if it is ahead of main and the tree is clean. 3. **The uncommitted diff** otherwise.

Ask only when the answer genuinely changes what gets reviewed and you cannot tell — dirty tree *and* they mentioned a PR, say. Never open with a questionnaire: this skill runs at the end of a session, sometimes inside an autonomous run, and three questions there are worse than a wrong guess you announced. Guess, say what you guessed, let them correct you.

Whatever you settle on, resolve it into **concrete paths, or a concrete git range, before dispatching**. Every reviewer must look at the same thing — otherwise "two of them agreed" means nothing, they just happened to read the same file. If the target is vague, resolve it and say what you resolved it to.

## Say what you are about to do

**Always, before launching anything.** Short, then go — this is not a request for permission, and you do not wait for an answer:

``` Reviewing: <target, and where it came from — "what we just did", "branch vs main", "you asked for src/auth.py"> <when $REPO is not the session's own checkout, show the resolved path so a wrong-tree review is caught before it runs> Running now: Codex <effort> · OpenCode <model> · ponytail <— or why one is missing Then: <what decides the Claude spend> ```

If they wanted something else they will say so, and interrupting is cheaper than an interrogation.

## Launch everything free, immediately

Codex, OpenCode and the ponytail lens cost nothing per run and take 30–70 seconds wall clock. There is never a reason to hold them back or make them conditional on a mode. Start the two external ones **in the background, both at once** — OpenCode spends about a minute just warming up — and do everything else while they run.

```bash RUN="$($SCRIPTS/run-dir.sh --slug <two-to-four words: the project and the job, e.g. skills-fixing-multi>)"

# The tree under review. Usually the session's own repo; set REVIEW_DIR to a # path or a different worktree when THAT is the target. Resolve it once and hand # it to every backend: cwd resets between these blocks, so without an explicit # --repo the reviewers silently read the session checkout and can "agree" on an # empty diff. REPO="$(git -C "${REVIEW_DIR:-.}" rev-parse --show-toplevel)"

$SCRIPTS/collect-context.sh --repo "$REPO" [--diff <spec>] [--paths "<paths>"] > "$RUN/ctx.md"

$SCRIPTS/review-prompt.sh --repo "$REPO" --target "<in words>" [--diff <spec>] [--paths "<paths>"] \ [--focus "<user text>"] --context "$RUN/ctx.md" > "$RUN/review.prompt.md" $SCRIPTS/ask.sh --repo "$REPO" --question-file "$RUN/review.prompt.md" --out-prefix "$RUN/review" \ --backend "codex,opencode:<model from probe>" --fallback <from probe> \ --effort <low|medium|high|xhigh|max> --timeout "${MULTI_REVIEW_TIMEOUT:-900}" ```

`run-dir.sh` prints this session's own directory, `/tmp/multi/<session>--<slug>`, and creates it. Two sessions reviewing at once used to share fixed `/tmp` names and overwrite each other's files. Shell variables do not survive between commands, so repeat that first line — and the `REPO=` line — in every later block that needs them; `--slug` only labels the directory the first time, so a different wording later still lands in the same place. Runs older than a week are swept.

`--diff` is what makes it a *change* review; leave it off and the reviewers read the actual code instead, with old code fully in scope. `--paths` narrows hard. `--target` is always required — it is the human sentence, and it is what keeps the reviewers pointed at the same thing. `--repo` is the *directory* they work in; it defaults to cwd, so you only think about it when the target is a different worktree, but passing `$REPO` always is free and removes the guesswork.

The probe at the top of this file ran with no `--repo`, so its `repo:`, branch, dirty-file and ahead-of-main numbers describe the **session checkout**. When `$REPO` is a different worktree, those numbers are for the wrong tree — re-run `$SCRIPTS/probe.sh --repo "$REPO"` to orient on the real target before you trust them.

`collect-context.sh` gathers the repo's `CLAUDE.md`/`AGENTS.md` and the `.claude/rules/*.md` matching the target, and every reviewer gets it. This is what separates this from three models guessing: an external reviewer that does not know the project's settled decisions spends its findings re-litigating them.

**The ponytail lens** — invoke the `ponytail:ponytail-review` skill on the same target whenever the probe found it. It hunts one thing, over-engineering, and that keeps the defect reviewers out of matters of taste entirely (see below). Its findings are a different kind of thing and never mix with defects: they get their own section and cannot corroborate or contradict a bug.

> If ponytail mode is *active*, its `SubagentStart` hook injects the YAGNI > ruleset into every sub-agent, including the ones hunting bugs. If findings > start reading like simplification advice, that is why; `PONYTAIL_SUBAGENT_MATCHER` > is the fix. Mention it once, move on.

## Then decide how much Claude to spend

The external reviewers are free; your sub-agents are the user's money. So do not guess the depth up front — **wait for the free results and decide on evidence**. A two-line change both reviewers called clean does not need three sub-agents. A change where Codex reports two HIGH and OpenCode disagrees with one of them does.

Say the decision in one line when you make it: *"going to normal — Codex found two HIGH, OpenCode contradicts one."*

An explicitly named mode skips all of this. Obey it.

| | Claude sub-agents | when | |---|---|---| | `lite` | `correctness` only | small, low-risk, external reviewers agree and found little | | `normal` *(default)* | `correctness` · `security` · `design` | anything heading for a PR | | `ultra` | those three, plus `execution`, plus an adversarial second Codex pass (`--adversarial`), plus one `verify` per single-source finding | expensive to get wrong, or asked for |

The adversarial pass needs Codex specifically; without it, `ultra` runs without that pass — the rest of the mode is unchanged.

Spawn them **in parallel, in one message**. Give each the target, the paths or range, the contents of `$RUN/ctx.md`, and the user's own words if there were any. Give them `$REPO` too and say it plainly — *run git and read files in `$REPO`, not your current directory* — because a sub-agent starts in the session checkout, and if the target is another worktree it would otherwise review the wrong tree, exactly as the CLI backends would without `--repo`.

**Model**: the argument if given, else `MULTI_REVIEWER_MODEL` from the probe, else the agent files' default (Sonnet). **No mode raises it on its own** — `ultra` buys depth through more angles and real verification, not a bigger model.

**`ultra` is not a deeper code review — it reviews whether the task got done.** Was there a plan and was it followed; is the thing actually finished or only finished-looking; what was silently skipped; what will detonate later. That needs the task context — the plan, the spec, the conversation. Hand `execution` what you actually know about the job. Without any of that, `ultra` degrades to `normal` plus an architecture angle, and you should say so rather than pretend.

## Judge

Normalize everything to `{file, line, severity, claim}`. Codex and OpenCode both answer the unified review prompt as `FILE:LINE | HIGH|MEDIUM|LOW | reason`, with repo-relative paths. OpenCode's file has two parts: `## <model>` listing every tool call it made, then `## Answer` with what it wrote in that unified format. Sub-agents report `FILE:LINE | SEVERITY | confidence NN` with two lines under it.

**Read OpenCode's call list before its findings.** It is there to answer one question: did this reviewer actually look at the code it is talking about? A finding about a file that never appears in the call list was invented, and it goes in `Dropped`. `(none — this reviewer answered without opening anything)` means the whole report is guesswork. `NO ANSWER` means it ran and said nothing: that reviewer was absent, say so as `Codex/Opencode FAILED: <reason>` from the one-line text in `*.dead` rather than reading silence as agreement.

Bucket by *the underlying problem*, not by wording — the same bug gets three different descriptions:

- **Corroborated** — two or more reviewers from different families (Claude / Codex / OpenCode). Leads the report; independent agreement is the strongest evidence this pipeline produces. - **Single-source** — one reviewer. Check each before the user sees it: open the cited lines, confirm it is real and reachable. In `ultra`, spawn one `verify` per finding instead an

--- name: code-review description: >- Code review by several models at once — Claude sub-agents, OpenAI Codex, and a cheap third reviewer via OpenCode — reconciled into one report. Reviews whatever is named: a diff, a branch, specific files, one function, a legacy module, a whole repo. Use for any review request, a second or third opinion, a cross-check before a PR, or "code-review", "multi", "consensus review". allowed-tools: Bash, Read, Grep, Glob, Agent, TodoWrite argument-hint: "[what to review, in words] [lite|normal|ultra] [haiku|sonnet|opus|fable] [low|medium|high|xhigh|max]" ---

# Multi-model code review

!`sh -c 'for p in "$CLAUDE_PLUGIN_ROOT/scripts" "$HOME/.claude/skills/multi/scripts" "./.claude/skills/multi/scripts"; do [ -x "$p/probe.sh" ] && { "$p/probe.sh"; echo "scripts-dir: $p"; exit 0; }; done; echo "probe: NOT FOUND — locate scripts/probe.sh in this plugin and run it yourself"'`

Several models read the same code, and you decide what reaches the user. That is the whole idea: one model invents problems and walks past real ones, and you cannot tell which from a single report. Independent models disagree, and the disagreement is the signal.

You are the judge, not a dispatcher. The reviewers propose; they do not vote, and none of them gets the last word. When they conflict, open the code and decide.

This is normally reached at the end of a session — work is done, PR or push comes next. Act like it: the question is "is this ready", not "here are some observations".

`$SCRIPTS` below is whatever the probe printed as `scripts-dir:`.

## The gate

From the probe lines above — they are already there, do not re-run it.

**No second reviewer family → stop.** This is multi-model review; the review pipeline can run two non-Claude families, Codex and OpenCode — without at least one of them there is nothing here that a single-model review does not already do. OpenRouter and Gemini are real second families, but this pipeline cannot run them as reviewers yet: they serve `/multi:ask`, not this skill. Say which is missing and point at `/multi:setup`. Do not quietly deliver a one-model review wearing a three-model label.

Anything else missing is a note, not a stop: no OpenCode, no ponytail, not a git repo (fine — then the target is files, not a diff). Name what was missing in the report and carry on.

Whatever is missing, point them at `/multi:setup` to connect it — it walks through this step by step and does not need them to know any of the above.

## Decide what you are reviewing

**Whatever the user named.** A diff, a branch, two files, one function, a line range, a module nobody has touched in three years, the whole repository. There is no fixed vocabulary here and no menu — read what they wrote and work out what they mean, the way a colleague would.

When nothing was named, in this order:

1. **What this session was about.** If you just wrote or changed something, that is the target — you know which files, what the task was, where you were unsure, what you fixed blind. That is better than a diff, which in a dirty tree also holds debug leftovers and unrelated edits, and which misses the old code the change leans on. 2. **The branch**, if it is ahead of main and the tree is clean. 3. **The uncommitted diff** otherwise.

Ask only when the answer genuinely changes what gets reviewed and you cannot tell — dirty tree *and* they mentioned a PR, say. Never open with a questionnaire: this skill runs at the end of a session, sometimes inside an autonomous run, and three questions there are worse than a wrong guess you announced. Guess, say what you guessed, let them correct you.

Whatever you settle on, resolve it into **concrete paths, or a concrete git range, before dispatching**. Every reviewer must look at the same thing — otherwise "two of them agreed" means nothing, they just happened to read the same file. If the target is vague, resolve it and say what you resolved it to.

## Say what you are about to do

**Always, before launching anything.** Short, then go — this is not a request for permission, and you do not wait for an answer:

``` Reviewing: <target, and where it came from — "what we just did", "branch vs main", "you asked for src/auth.py"> <when $REPO is not the session's own checkout, show the resolved path so a wrong-tree review is caught before it runs> Running now: Codex <effort> · OpenCode <model> · ponytail <— or why one is missing Then: <what decides the Claude spend> ```

If they wanted something else they will say so, and interrupting is cheaper than an interrogation.

## Launch everything free, immediately

Codex, OpenCode and the ponytail lens cost nothing per run and take 30–70 seconds wall clock. There is never a reason to hold them back or make them conditional on a mode. Start the two external ones **in the background, both at once** — OpenCode spends about a minute just warming up — and do everything else while they run.

```bash RUN="$($SCRIPTS/run-dir.sh --slug <two-to-four words: the project and the job, e.g. skills-fixing-multi>)"

# The tree under review. Usually the session's own repo; set REVIEW_DIR to a # path or a different worktree when THAT is the target. Resolve it once and hand # it to every backend: cwd resets between these blocks, so without an explicit # --repo the reviewers silently read the session checkout and can "agree" on an # empty diff. REPO="$(git -C "${REVIEW_DIR:-.}" rev-parse --show-toplevel)"

$SCRIPTS/collect-context.sh --repo "$REPO" [--diff <spec>] [--paths "<paths>"] > "$RUN/ctx.md"

$SCRIPTS/review-prompt.sh --repo "$REPO" --target "<in words>" [--diff <spec>] [--paths "<paths>"] \ [--focus "<user text>"] --context "$RUN/ctx.md" > "$RUN/review.prompt.md" $SCRIPTS/ask.sh --repo "$REPO" --question-file "$RUN/review.prompt.md" --out-prefix "$RUN/review" \ --backend "codex,opencode:<model from probe>" --fallback <from probe> \ --effort <low|medium|high|xhigh|max> --timeout "${MULTI_REVIEW_TIMEOUT:-900}" ```

`run-dir.sh` prints this session's own directory, `/tmp/multi/<session>--<slug>`, and creates it. Two sessions reviewing at once used to share fixed `/tmp` names and overwrite each other's files. Shell variables do not survive between commands, so repeat that first line — and the `REPO=` line — in every later block that needs them; `--slug` only labels the directory the first time, so a different wording later still lands in the same place. Runs older than a week are swept.

`--diff` is what makes it a *change* review; leave it off and the reviewers read the actual code instead, with old code fully in scope. `--paths` narrows hard. `--target` is always required — it is the human sentence, and it is what keeps the reviewers pointed at the same thing. `--repo` is the *directory* they work in; it defaults to cwd, so you only think about it when the target is a different worktree, but passing `$REPO` always is free and removes the guesswork.

The probe at the top of this file ran with no `--repo`, so its `repo:`, branch, dirty-file and ahead-of-main numbers describe the **session checkout**. When `$REPO` is a different worktree, those numbers are for the wrong tree — re-run `$SCRIPTS/probe.sh --repo "$REPO"` to orient on the real target before you trust them.

`collect-context.sh` gathers the repo's `CLAUDE.md`/`AGENTS.md` and the `.claude/rules/*.md` matching the target, and every reviewer gets it. This is what separates this from three models guessing: an external reviewer that does not know the project's settled decisions spends its findings re-litigating them.

**The ponytail lens** — invoke the `ponytail:ponytail-review` skill on the same target whenever the probe found it. It hunts one thing, over-engineering, and that keeps the defect reviewers out of matters of taste entirely (see below). Its findings are a different kind of thing and never mix with defects: they get their own section and cannot corroborate or contradict a bug.

> If ponytail mode is *active*, its `SubagentStart` hook injects the YAGNI > ruleset into every sub-agent, including the ones hunting bugs. If findings > start reading like simplification advice, that is why; `PONYTAIL_SUBAGENT_MATCHER` > is the fix. Mention it once, move on.

## Then decide how much Claude to spend

The external reviewers are free; your sub-agents are the user's money. So do not guess the depth up front — **wait for the free results and decide on evidence**. A two-line change both reviewers called clean does not need three sub-agents. A change where Codex reports two HIGH and OpenCode disagrees with one of them does.

Say the decision in one line when you make it: *"going to normal — Codex found two HIGH, OpenCode contradicts one."*

An explicitly named mode skips all of this. Obey it.

| | Claude sub-agents | when | |---|---|---| | `lite` | `correctness` only | small, low-risk, external reviewers agree and found little | | `normal` *(default)* | `correctness` · `security` · `design` | anything heading for a PR | | `ultra` | those three, plus `execution`, plus an adversarial second Codex pass (`--adversarial`), plus one `verify` per single-source finding | expensive to get wrong, or asked for |

The adversarial pass needs Codex specifically; without it, `ultra` runs without that pass — the rest of the mode is unchanged.

Spawn them **in parallel, in one message**. Give each the target, the paths or range, the contents of `$RUN/ctx.md`, and the user's own words if there were any. Give them `$REPO` too and say it plainly — *run git and read files in `$REPO`, not your current directory* — because a sub-agent starts in the session checkout, and if the target is another worktree it would otherwise review the wrong tree, exactly as the CLI backends would without `--repo`.

**Model**: the argument if given, else `MULTI_REVIEWER_MODEL` from the probe, else the agent files' default (Sonnet). **No mode raises it on its own** — `ultra` buys depth through more angles and real verification, not a bigger model.

**`ultra` is not a deeper code review — it reviews whether the task got done.** Was there a plan and was it followed; is the thing actually finished or only finished-looking; what was silently skipped; what will detonate later. That needs the task context — the plan, the spec, the conversation. Hand `execution` what you actually know about the job. Without any of that, `ultra` degrades to `normal` plus an architecture angle, and you should say so rather than pretend.

## Judge

Normalize everything to `{file, line, severity, claim}`. Codex and OpenCode both answer the unified review prompt as `FILE:LINE | HIGH|MEDIUM|LOW | reason`, with repo-relative paths. OpenCode's file has two parts: `## <model>` listing every tool call it made, then `## Answer` with what it wrote in that unified format. Sub-agents report `FILE:LINE | SEVERITY | confidence NN` with two lines under it.

**Read OpenCode's call list before its findings.** It is there to answer one question: did this reviewer actually look at the code it is talking about? A finding about a file that never appears in the call list was invented, and it goes in `Dropped`. `(none — this reviewer answered without opening anything)` means the whole report is guesswork. `NO ANSWER` means it ran and said nothing: that reviewer was absent, say so as `Codex/Opencode FAILED: <reason>` from the one-line text in `*.dead` rather than reading silence as agreement.

Bucket by *the underlying problem*, not by wording — the same bug gets three different descriptions:

- **Corroborated** — two or more reviewers from different families (Claude / Codex / OpenCode). Leads the report; independent agreement is the strongest evidence this pipeline produces. - **Single-source** — one reviewer. Check each before the user sees it: open the cited lines, confirm it is real and reachable. In `ultra`, spawn one `verify` per finding instead an

--- name: code-review description: >- Code review by several models at once — Claude sub-agents, OpenAI Codex, and a cheap third reviewer via OpenCode — reconciled into one report. Reviews whatever is named: a diff, a branch, specific files, one function, a legacy module, a whole repo. Use for any review request, a second or third opinion, a cross-check before a PR, or "code-review", "multi", "consensus review". allowed-tools: Bash, Read, Grep, Glob, Agent, TodoWrite argument-hint: "[what to review, in words] [lite|normal|ultra] [haiku|sonnet|opus|fable] [low|medium|high|xhigh|max]" ---

# Multi-model code review

!`sh -c 'for p in "$CLAUDE_PLUGIN_ROOT/scripts" "$HOME/.claude/skills/multi/scripts" "./.claude/skills/multi/scripts"; do [ -x "$p/probe.sh" ] && { "$p/probe.sh"; echo "scripts-dir: $p"; exit 0; }; done; echo "probe: NOT FOUND — locate scripts/probe.sh in this plugin and run it yourself"'`

Several models read the same code, and you decide what reaches the user. That is the whole idea: one model invents problems and walks past real ones, and you cannot tell which from a single report. Independent models disagree, and the disagreement is the signal.

You are the judge, not a dispatcher. The reviewers propose; they do not vote, and none of them gets the last word. When they conflict, open the code and decide.

This is normally reached at the end of a session — work is done, PR or push comes next. Act like it: the question is "is this ready", not "here are some observations".

`$SCRIPTS` below is whatever the probe printed as `scripts-dir:`.

## The gate

From the probe lines above — they are already there, do not re-run it.

**No second reviewer family → stop.** This is multi-model review; the review pipeline can run two non-Claude families, Codex and OpenCode — without at least one of them there is nothing here that a single-model review does not already do. OpenRouter and Gemini are real second families, but this pipeline cannot run them as reviewers yet: they serve `/multi:ask`, not this skill. Say which is missing and point at `/multi:setup`. Do not quietly deliver a one-model review wearing a three-model label.

Anything else missing is a note, not a stop: no OpenCode, no ponytail, not a git repo (fine — then the target is files, not a diff). Name what was missing in the report and carry on.

Whatever is missing, point them at `/multi:setup` to connect it — it walks through this step by step and does not need them to know any of the above.

## Decide what you are reviewing

**Whatever the user named.** A diff, a branch, two files, one function, a line range, a module nobody has touched in three years, the whole repository. There is no fixed vocabulary here and no menu — read what they wrote and work out what they mean, the way a colleague would.

When nothing was named, in this order:

1. **What this session was about.** If you just wrote or changed something, that is the target — you know which files, what the task was, where you were unsure, what you fixed blind. That is better than a diff, which in a dirty tree also holds debug leftovers and unrelated edits, and which misses the old code the change leans on. 2. **The branch**, if it is ahead of main and the tree is clean. 3. **The uncommitted diff** otherwise.

Ask only when the answer genuinely changes what gets reviewed and you cannot tell — dirty tree *and* they mentioned a PR, say. Never open with a questionnaire: this skill runs at the end of a session, sometimes inside an autonomous run, and three questions there are worse than a wrong guess you announced. Guess, say what you guessed, let them correct you.

Whatever you settle on, resolve it into **concrete paths, or a concrete git range, before dispatching**. Every reviewer must look at the same thing — otherwise "two of them agreed" means nothing, they just happened to read the same file. If the target is vague, resolve it and say what you resolved it to.

## Say what you are about to do

**Always, before launching anything.** Short, then go — this is not a request for permission, and you do not wait for an answer:

``` Reviewing: <target, and where it came from — "what we just did", "branch vs main", "you asked for src/auth.py"> <when $REPO is not the session's own checkout, show the resolved path so a wrong-tree review is caught before it runs> Running now: Codex <effort> · OpenCode <model> · ponytail <— or why one is missing Then: <what decides the Claude spend> ```

If they wanted something else they will say so, and interrupting is cheaper than an interrogation.

## Launch everything free, immediately

Codex, OpenCode and the ponytail lens cost nothing per run and take 30–70 seconds wall clock. There is never a reason to hold them back or make them conditional on a mode. Start the two external ones **in the background, both at once** — OpenCode spends about a minute just warming up — and do everything else while they run.

```bash RUN="$($SCRIPTS/run-dir.sh --slug <two-to-four words: the project and the job, e.g. skills-fixing-multi>)"

# The tree under review. Usually the session's own repo; set REVIEW_DIR to a # path or a different worktree when THAT is the target. Resolve it once and hand # it to every backend: cwd resets between these blocks, so without an explicit # --repo the reviewers silently read the session checkout and can "agree" on an # empty diff. REPO="$(git -C "${REVIEW_DIR:-.}" rev-parse --show-toplevel)"

$SCRIPTS/collect-context.sh --repo "$REPO" [--diff <spec>] [--paths "<paths>"] > "$RUN/ctx.md"

$SCRIPTS/review-prompt.sh --repo "$REPO" --target "<in words>" [--diff <spec>] [--paths "<paths>"] \ [--focus "<user text>"] --context "$RUN/ctx.md" > "$RUN/review.prompt.md" $SCRIPTS/ask.sh --repo "$REPO" --question-file "$RUN/review.prompt.md" --out-prefix "$RUN/review" \ --backend "codex,opencode:<model from probe>" --fallback <from probe> \ --effort <low|medium|high|xhigh|max> --timeout "${MULTI_REVIEW_TIMEOUT:-900}" ```

`run-dir.sh` prints this session's own directory, `/tmp/multi/<session>--<slug>`, and creates it. Two sessions reviewing at once used to share fixed `/tmp` names and overwrite each other's files. Shell variables do not survive between commands, so repeat that first line — and the `REPO=` line — in every later block that needs them; `--slug` only labels the directory the first time, so a different wording later still lands in the same place. Runs older than a week are swept.

`--diff` is what makes it a *change* review; leave it off and the reviewers read the actual code instead, with old code fully in scope. `--paths` narrows hard. `--target` is always required — it is the human sentence, and it is what keeps the reviewers pointed at the same thing. `--repo` is the *directory* they work in; it defaults to cwd, so you only think about it when the target is a different worktree, but passing `$REPO` always is free and removes the guesswork.

The probe at the top of this file ran with no `--repo`, so its `repo:`, branch, dirty-file and ahead-of-main numbers describe the **session checkout**. When `$REPO` is a different worktree, those numbers are for the wrong tree — re-run `$SCRIPTS/probe.sh --repo "$REPO"` to orient on the real target before you trust them.

`collect-context.sh` gathers the repo's `CLAUDE.md`/`AGENTS.md` and the `.claude/rules/*.md` matching the target, and every reviewer gets it. This is what separates this from three models guessing: an external reviewer that does not know the project's settled decisions spends its findings re-litigating them.

**The ponytail lens** — invoke the `ponytail:ponytail-review` skill on the same target whenever the probe found it. It hunts one thing, over-engineering, and that keeps the defect reviewers out of matters of taste entirely (see below). Its findings are a different kind of thing and never mix with defects: they get their own section and cannot corroborate or contradict a bug.

> If ponytail mode is *active*, its `SubagentStart` hook injects the YAGNI > ruleset into every sub-agent, including the ones hunting bugs. If findings > start reading like simplification advice, that is why; `PONYTAIL_SUBAGENT_MATCHER` > is the fix. Mention it once, move on.

## Then decide how much Claude to spend

The external reviewers are free; your sub-agents are the user's money. So do not guess the depth up front — **wait for the free results and decide on evidence**. A two-line change both reviewers called clean does not need three sub-agents. A change where Codex reports two HIGH and OpenCode disagrees with one of them does.

Say the decision in one line when you make it: *"going to normal — Codex found two HIGH, OpenCode contradicts one."*

An explicitly named mode skips all of this. Obey it.

| | Claude sub-agents | when | |---|---|---| | `lite` | `correctness` only | small, low-risk, external reviewers agree and found little | | `normal` *(default)* | `correctness` · `security` · `design` | anything heading for a PR | | `ultra` | those three, plus `execution`, plus an adversarial second Codex pass (`--adversarial`), plus one `verify` per single-source finding | expensive to get wrong, or asked for |

The adversarial pass needs Codex specifically; without it, `ultra` runs without that pass — the rest of the mode is unchanged.

Spawn them **in parallel, in one message**. Give each the target, the paths or range, the contents of `$RUN/ctx.md`, and the user's own words if there were any. Give them `$REPO` too and say it plainly — *run git and read files in `$REPO`, not your current directory* — because a sub-agent starts in the session checkout, and if the target is another worktree it would otherwise review the wrong tree, exactly as the CLI backends would without `--repo`.

**Model**: the argument if given, else `MULTI_REVIEWER_MODEL` from the probe, else the agent files' default (Sonnet). **No mode raises it on its own** — `ultra` buys depth through more angles and real verification, not a bigger model.

**`ultra` is not a deeper code review — it reviews whether the task got done.** Was there a plan and was it followed; is the thing actually finished or only finished-looking; what was silently skipped; what will detonate later. That needs the task context — the plan, the spec, the conversation. Hand `execution` what you actually know about the job. Without any of that, `ultra` degrades to `normal` plus an architecture angle, and you should say so rather than pretend.

## Judge

Normalize everything to `{file, line, severity, claim}`. Codex and OpenCode both answer the unified review prompt as `FILE:LINE | HIGH|MEDIUM|LOW | reason`, with repo-relative paths. OpenCode's file has two parts: `## <model>` listing every tool call it made, then `## Answer` with what it wrote in that unified format. Sub-agents report `FILE:LINE | SEVERITY | confidence NN` with two lines under it.

**Read OpenCode's call list before its findings.** It is there to answer one question: did this reviewer actually look at the code it is talking about? A finding about a file that never appears in the call list was invented, and it goes in `Dropped`. `(none — this reviewer answered without opening anything)` means the whole report is guesswork. `NO ANSWER` means it ran and said nothing: that reviewer was absent, say so as `Codex/Opencode FAILED: <reason>` from the one-line text in `*.dead` rather than reading silence as agreement.

Bucket by *the underlying problem*, not by wording — the same bug gets three different descriptions:

- **Corroborated** — two or more reviewers from different families (Claude / Codex / OpenCode). Leads the report; independent agreement is the strongest evidence this pipeline produces. - **Single-source** — one reviewer. Check each before the user sees it: open the cited lines, confirm it is real and reachable. In `ultra`, spawn one `verify` per finding instead an