1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
---
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).
|
