---
name: pi-review-panel
description: >-
  Reviews whatever the user specifies — a diff, a design doc, a proposal, a
  file, a question — with a panel of external models driven by the `pi` CLI,
  then verifies and synthesizes their findings into one report, with per-model
  cost. ONLY use this skill when the user explicitly asks for it (e.g. "run a
  pi review panel", "panel review", "review this with the pi models") — never
  invoke it on your own initiative for ordinary review requests. The user may
  specify a subset of the default provider/model pairs, or a different set
  entirely.
---

# pi review panel

Review something with several external models via `pi`, each run
independently, then verify their claims and synthesize.

This is a **fan-out** in the sense of the pi-subagent skill, which does the
running: read its SKILL.md first and follow it for the workdir, launching,
monitoring, retries, cost table and verification. `$SA` below is that skill's
directory. What follows is only what a review panel adds.

## 0. Panel composition

The default panel is six runs:

| provider | model | name |
|---|---|---|
| fireworks | `accounts/fireworks/models/kimi-k3` | fw-kimi-k3 |
| openrouter | `moonshotai/kimi-k3` | or-kimi-k3 |
| openrouter | `z-ai/glm-5.3-flash` | or-glm-5.3-flash |
| openrouter | `deepseek/deepseek-v4.1-flash` | or-deepseek-v4.1-flash |
| openrouter | `google/gemini-3.7-flash` | or-gemini-3.7-flash |
| openrouter | `z-ai/glm-5.3` | or-glm-5.3 |

If the user names specific providers/models, use exactly those instead — don't
silently add the defaults back. A provider this machine lacks
(`pi --offline --list-models <model>` shows nothing for it) is dropped and
named in the report, not substituted.

## 1. Establish what is under review

**Review what the user specified.** It is whatever they point at — a document,
a proposal, a single file, a design question, a diff. Take their framing as
given.

Only when they didn't specify, default to the diff: uncommitted changes if any
(`git status`, `git diff`), otherwise the current branch against its merge-base
with the default branch. Ask only if genuinely ambiguous.

State at the top of the final report exactly what was reviewed (commit range,
"working tree", or the file path), and snapshot it as pi-subagent §1 says.

## 2. Write the review brief

`$P/brief.md`, following pi-subagent §2, with these specifics:

- The question up front: "find bugs in this diff" and "can you beat this
  design" are different reviews.
- The reviewer stance: a strict senior reviewer, looking for errors, incorrect
  claims (especially documented numbers, or behavior the artifact does not
  actually produce), missing cases, unnecessary complexity.
- For each finding: location, severity (blocker / major / minor / nit), and a
  one-paragraph justification.
- Everything they can reach is **read-only**. Reviewers need to run things to
  verify, so this is read-only by instruction (pi-subagent §3, level 2), not
  `--tools`.
- A fixed verdict pair as the last line: `VERDICT: SHIP` /
  `VERDICT: DO NOT SHIP`, or for a design review `VERDICT: PROPOSAL IS BEST` /
  `VERDICT: BETTER IDEA FOUND — <name>`.

## 3. Run the panel

All members at once, one line per row of the table, with `--session` so that
contradictions can be put back to the reviewers in §4:

```bash
"$SA/run-agent.sh" --session --deliver "the full markdown review" "$P" fireworks "accounts/fireworks/models/kimi-k3" fw-kimi-k3 > "$P/out/_fw-kimi-k3.log" 2>&1 &
# ...and so on for each member
```

Expect 5–30 minutes; use them as pi-subagent §5 says. A member succeeded if
its review ends with a verdict line. A provider that fails twice doesn't sink
the panel: the same model on the other provider usually keeps the coverage.

## 4. Synthesize

Verify first (pi-subagent §7): the reviews are raw material, and the places
where reviewers contradict each other are where the real answer usually is.

Where two reviewers contradict each other on something that matters, follow
each one up with the other's finding (pi-subagent §10) before you settle it:

```bash
"$SA/run-agent.sh" --followup "Another reviewer says: <finding, with its evidence>. \
Check it against the code and say who is right, with the command and output \
that decides it. End with: VERDICT: <same pair as before>" \
  "$P" fireworks "accounts/fireworks/models/kimi-k3" fw-kimi-k3
```

Their replies sharpen the question; they don't answer it. A reviewer giving
way is not proof — run the deciding experiment yourself either way, and tally
verdicts from the original reviews, noting any that changed. Once a member has
been followed up, its original review is `<name>.round1.md` and `<name>.md` is
the reply.

The report:

- What was reviewed.
- Findings deduplicated, ranked by severity, each tagged with how many members
  raised it and whether **you** confirmed it, on what.
- A "Dropped" section naming what you could not confirm and why. Not optional —
  it's what makes the confirmed findings trustworthy.
- The verdict tally and any disagreement worth the author's attention, with who
  was right where you settled it.
- The cost table (`"$SA/status.sh" "$P"`), and a sentence on cost per useful
  finding when the spread is large — it informs whether the panel should
  shrink next time.
- Paths to the per-model reviews, copied somewhere durable if the findings
  matter (pi-subagent §9).