Panel Review

Panel Review — Skills as Review Lenses

Review one diff through N lenses, where every lens is an installed skill and every lens runs as its own sub-agent with an isolated context. The orchestrator composes the roster, fans the lens nodes out, adversarially verifies every finding against the actual code, and synthesizes one severity-ranked report. No lens is hardcoded: the defaults are conventions, the roster is yours.

The target is any change boundary, at any phase: uncommitted work-in-progress, the current branch's accumulated diff, one stacked layer, or an actual pull request. A PR is one kind of target, not a precondition — reviewing before the PR exists is a first-class use. The PR-readiness evidence gate is a lens you get when the boundary is heading to a PR, not a gate on running the review.

This skill is an instance of graph-engineering — load that skill for the generic node/topology/runtime machinery. This file owns what is review-specific: the invocation grammar, the lens registry, the PR-readiness gate, and the report.

Invocation Grammar

/panel-review [target] [modifiers] [lens...]

Examples: /panel-review · /panel-review #482 thorough · /panel-review hexagonal-architecture domain-driven-design structure-codebase · /panel-review only xstate react-testing · /panel-review -testing post

Unknown tokens that don't match an installed skill: say so and list near-matches; don't guess.

Workflow

1. Resolve the target diff

• PR target: gh pr view <n> --json title,body,baseRefName,files,additions,deletions and gh pr diff <n>.
• Branch target: diff against the merge base — git diff $(git merge-base <default-branch> HEAD)...HEAD plus uncommitted changes if present (say whether they're included).
• wip target: git diff HEAD — the uncommitted working-tree and staged changes only.
• Stacked boundary: when reliable stack metadata identifies the branch as stacked, review git diff <immediate-parent>...HEAD, not the cumulative trunk diff.

No target needs to be a PR. The review runs identically at any phase; only the readiness lens cares whether the boundary claims PR readiness (see references/lenses.md).

STOP and report instead of reviewing when the diff is empty or the target can't be resolved.

2. Scout inline

A few cheap tool calls, no sub-agents: categorize changed files (production / test / config / docs), read the project's CLAUDE.md and key configs for traits, and collect the signals references/lenses.md needs for auto-detection. The scout also captures the change's own claim (PR title/body, plan slice, commit messages, or the user's stated intent for in-progress work) — the review judges the diff against its claim.

3. Compose the roster

Per references/lenses.md: built-in lenses (readiness, quality) + core defaults + auto-detected conditional lenses, then apply the user's only/add/remove tokens. Show the final roster and rough scale (N lens nodes + verification) in one line before launching; for large rosters (>8 nodes) confirm with the user first unless they said thorough.

4. Run the graph

Execute per graph-engineering runtimes — the Workflow tool with references/workflow-template.md when available, Agent-tool fan-out otherwise, sequential degraded mode as the labelled last resort. Every lens node loads exactly one skill, receives the diff scope and the sibling-lens list (to keep boundaries disjoint), reads surrounding code as needed, and returns schema-shaped findings with file:line evidence. Lens nodes are read-only.

5. Verify and synthesize

Per graph-engineering: dedup by file/line/claim (multi-lens agreement is signal — note it), adversarially verify every surviving finding with an independent node mandated to refute, keep unverifiable distinct from refuted, and surface cross-lens conflicts with both arguments instead of silently picking a winner.

6. Report

## Review: <target> — <one-line claim>

**Roster:** <lenses run> · **Scale:** <N nodes, M findings verified> · **Runtime:** <workflow | agent fan-out | sequential (degraded)>

| Lens | Verdict | Confirmed findings |
|------|---------|--------------------|
| readiness *(PR-bound targets only)* | ✅/❌/⚠️ | n |
| <skill lens> | ✅/❌/⚠️ | n |

**Recommendation:** APPROVE / REQUEST CHANGES / NEEDS DISCUSSION

### Confirmed findings (ranked)
🔴/⚠️/💡 **[lens] title** — `file:line`
Problem · Why it matters · Suggested fix (with copy-pasteable fix_prompt)

### Conflicts between lenses      ← only when present, both arguments
### Unverifiable claims           ← reported, never silently dropped
### Clean                         ← what was inspected and found sound
### Not covered                   ← lenses not run, scopes not assessable, node failures

Recommendation rules: any confirmed critical → REQUEST CHANGES; unresolved lens conflict or failed readiness gate → NEEDS DISCUSSION; otherwise APPROVE with the minors listed.

7. Post (only when asked)

With the post token and a PR target: write the report to a scratch file and post it with gh pr comment <number> --body-file <file> (or a formal gh pr review --comment/--request-changes --body-file <file>), headed ## 🤖 /panel-review with the roster named — never interpolate the report body through shell arguments. Never post without the explicit token; never use --approve on the user's behalf.

Boundaries

• During development, use the focused agents (tdd-guardian, ts-enforcer, refactor-scan) — this skill is the whole-boundary review at the end.
• double-check answers a different question. This skill is breadth through your own standards: many same-provider sub-agents, each applying one of your installed skills to the diff, findings verified and merged into one report — wide coverage, but every node shares the host model's blind spots. double-check is independence: one strong reviewer, preferably from a different provider, starting cold with no inherited context, checking scope fidelity against the original requirements and arguing findings across rounds until genuine convergence. Fan out with /panel-review for coverage; bring in double-check when the risk is that you (and every sub-agent you spawn) are wrong the same way — high stakes, contested calls, or a final independent gate before shipping. They compose: /panel-review first, double-check last.
• /code-review (built-in) runs Anthropic's fixed issue-class lenses; this skill exists precisely to compose your skills instead.
• The review reads the target repository's own conventions (its CLAUDE.md, glossary, ADRs) as part of the scout; a lens finding that contradicts an explicit local convention is reported as a conflict, not enforced.

Completion Check

• Was the roster composed (defaults + detection + user tokens) and shown before launch?
• Did every lens node load its one skill and stay inside its boundary?
• Did every reported finding survive independent adversarial verification, with file:line evidence?
• Are conflicts, unverifiable claims, clean areas, and coverage gaps all explicit in the report?
• When the readiness lens ran, does its verdict follow references/pr-readiness.md, including the mutation-evidence freshness model — and when it was skipped for a mid-development target, is that listed under "Not covered"?
• Was anything posted to GitHub only with the explicit post token?