panel

---
name: panel
description: >
  Runs a code change past five archetype reviewers (The Laziest Senior Dev, The
  3am On-Call SRE, The Security Paranoiac, The Junior Who Asks Why, The PM Who
  Only Reads the Title). Each runs as an isolated subagent. Prints one
  screenshot-ready verdict card with scores and one-line roasts, and keeps real
  findings apart from the jokes. Use for /panel, "roast my PR", "review panel",
  "panel review this diff".
argument-hint: "[PR number or URL | branch | commit range | nothing = current changes]"
---

# /panel

Five reviewers. Five isolated subagents. One verdict card.

The roasts are for the screenshot. The findings are for the merge button.
Never mix them up: a joke is never a finding, and a real finding is never
softened into a joke.

## 1. Collect the change

Work out what to review from the argument:

| Argument | Diff | Title and description |
|---|---|---|
| PR number or URL | `gh pr diff <n>` | `gh pr view <n> --json title,body` |
| branch name | `git diff <base>...<branch>` (base: `main`, else `master`) | last commit subject on the branch, plus branch name |
| commit range `a..b` | `git diff a..b` | `git log --format=%s a..b` |
| nothing | `git diff HEAD` (staged and unstaged); if empty, `git show HEAD` | uncommitted: "Uncommitted changes" plus branch name; last commit: its subject and body |

Also get the file list with line counts: same command with `--stat`.

If the diff is empty, say "Nothing to review." and stop. If the diff is larger
than about 3,000 lines, tell the user and review only the first 3,000 lines.
Say on the card that it was truncated.

## 2. Run the panel

Read the five persona files in `personas/`, next to this file:

- `personas/lazy-senior.md`
- `personas/oncall-sre.md`
- `personas/security-paranoiac.md`
- `personas/junior-asks-why.md`
- `personas/pm-title-only.md`

Dispatch **five subagents in parallel, in a single message**, one per persona.
Use the general-purpose agent type. Each subagent is isolated: it gets only
its own prompt and never sees the other reviewers' output or this
conversation.

Each subagent's prompt is, in this order:

1. The full text of its persona file.
2. The **review contract** below, verbatim.
3. The change:
   - **The PM** gets only the title, the description, and the `--stat` file
     list. Never give the PM the diff. That is the joke, and it is also the
     test: can the files alone contradict the title?
   - **Everyone else** gets the title, the description, and the full diff. They
     may read the surrounding files in the repo to check a suspicion, but they
     must not edit anything.

### Review contract (paste verbatim into every subagent prompt)

```
You are one reviewer on a five-person panel. Stay fully in character for the
roast. Be completely serious for the findings.

Reply with ONLY a JSON object, no prose before or after:

{
  "persona": "<your id from the persona file>",
  "score": <integer 1-10, your rubric>,
  "roast": "<one line, max 100 characters, in your voice>",
  "findings": [
    {
      "severity": "blocker" | "major" | "minor",
      "file": "<path>",
      "line": <line number in the new file, or null>,
      "title": "<max 80 characters, plain words>",
      "failure": "<the concrete input or situation, and the wrong result>",
      "fix": "<the smallest fix>"
    }
  ]
}

Rules:
- A finding is a real defect or risk with a concrete failure case. No case,
  no finding. Style, taste, and naming are not findings.
- Read the lines again before you report. If you are not sure, leave it out.
- blocker: wrong result, crash, security hole, data loss, or outage in normal
  use. major: real failure under a plausible condition. minor: real but small.
- At most 5 findings. An empty list is a good answer for a good change.
- The roast is about the code, never the author. No slurs, nothing about
  people's identity. It can be harsh; it cannot be cruel.
- Your score follows your rubric. Do not grade on a curve.
```

## 3. Merge the results

When all five return:

1. Parse each JSON reply. If one is not valid JSON, ask that subagent once to
   resend only the JSON. If it fails again, give it score `null` and the roast
   "(left the meeting)".
2. **Check every finding yourself** against the diff: the line must exist and
   the failure must actually follow from the code. Drop the ones that do not
   hold. This is the step that keeps the panel honest. Five reviewers produce
   noise; you are the filter.
3. **Merge duplicates.** The same defect at the same place, found by several
   reviewers, becomes one finding with all their ids in `by`. Keep the highest
   severity among them.
4. Write `panel.json` to the system temp directory (a `review-panel-<short
   sha or timestamp>` folder), never into the repo:

```json
{
  "title": "<PR or commit title>",
  "target": "<what was reviewed, e.g. PR #42, HEAD, main...feature>",
  "truncated": false,
  "reviews": [ <the five persona replies as returned, after step 1> ],
  "findings": [ <merged, checked findings, each with "by": ["<persona id>", ...]> ],
  "dropped": <number of findings dropped in step 2>
}
```

## 4. Render the card

Run the renderer (Python 3, standard library only). It sits next to this
file:

```bash
python "<this skill's dir>/scripts/render_card.py" "<tmp>/panel.json" --png
```

It prints the markdown card to stdout and writes `card.md`, `card.html`, and,
with `--png`, `card.png` next to `panel.json`. The PNG needs Chrome, Chromium,
or Edge. If none is found, the renderer says so and still writes the HTML.

The renderer computes the panel score and the verdict, so they do not depend
on your mood:

- **BLOCKED**: at least one blocker finding.
- **CHANGES REQUESTED**: at least one major finding.
- **SHIP IT**: otherwise.

If Python is not available, build the same markdown card by hand from
`panel.json`, using the same layout as `examples/card.md` in the repo.

## 5. Reply

Print the markdown card exactly as the renderer produced it. Then add one
line with the paths to `card.png` (or `card.html`). Do not repeat the
findings in prose. Do not add a summary, because the card is the summary.

Change no code. The panel reviews; it does not fix. If the user then asks
for fixes, the findings list is the to-do list.

• SKILL.md 6 KB
• personas/junior-asks-why.md 2 KB
• personas/lazy-senior.md 1 KB
• personas/oncall-sre.md 1 KB
• personas/pm-title-only.md 2 KB
• personas/security-paranoiac.md 2 KB
• scripts/render_card.py 11 KB