Review Board

---
name: review-board
description: The full pre-merge review — convene a board of expert hats (pragmatic staff engineer, domain expert, security, UX, UI, PM, marketing, sales) as parallel review subagents, then synthesize ONE ranked verdict and a prioritized plan to fix everything. Use for a PR, branch, commit range, or uncommitted work when a thorough multi-perspective review is warranted; it combines correctness, security, product, and UX lenses in one pass.
effort: max
argument-hint: "[nothing = local changes · commit hash · a..b range · branch/ref · PR number · -- pathspec]"
allowed-tools: Read, Grep, Glob, Bash, Agent
---

# /review-board — the panel reviews the change, you synthesize a fix plan

Convene a board of expert hats; each reviews the change through ONE lens **in parallel**;
then YOU (the parent) synthesize one ranked verdict and an ordered plan to fix everything.
This is the on-demand review — point it at a PR, a branch, a commit/range, or your
uncommitted local changes. It combines the staff-correctness, security, and
product lenses into one panel, across **all** areas (portal/runner/mcp/packs).
**Read-only: the board reviews; it never edits.** The deliverable is a *fix plan*, not just notes.

## 1. Scope the change — PR, branch, commit, range, or local edits
Resolve `$1` into a concrete diff + file list, then read it yourself first. Inputs:
- **nothing (default)** → your **uncommitted local changes**: `git diff HEAD` (staged + unstaged) plus untracked files from `git status --porcelain`. The "review what I'm working on right now" case.
- **a commit hash** (`a1b2c3d`) → that commit alone: `git show <hash>` / `git diff <hash>^..<hash>`.
- **a range** (`a..b`, `a...b`, `HEAD~3..HEAD`) → `git diff <range>`.
- **a branch / ref** (`feat-x`, a tag) → its diff vs the base: `git diff main...<ref>`.
- **a PR number** (`123` / `#123`) → `gh pr view <n> --json title,body,files` + `gh pr diff <n>` (read the title/body for **intent**).
- **a pathspec / file(s)** (`-- runner/…`) → narrows ANY of the above to those paths.

**Mind a shared working tree.** With a concurrent agent (Codex) editing, "local changes" can include work that isn't yours — `git diff HEAD` shows everyone's. Narrow with a pathspec, or review a specific commit/range/PR instead, when you want only your slice.

For **intent** on a non-PR scope, read the commit message(s) in range, or — for uncommitted work — the `.agent/tasks/` context (the in-progress task's `task.md` + `log.md`); if what the change is *for* is unclear, say so (a reviewer who doesn't know the goal judges the wrong things).

**Announce the resolved scope before convening the board** — the input mode + the exact file list. Note which areas it touches — portal/ (Elixir), runner/ or mcp/ (Go), packs/ (YAML), marketing, billing/pricing, docs — which drives the hats.

## 2. Convene the board (the hats the change earns)
**Standing hats — always, for any code change:**
- **Pragmatic staff engineer** — correctness & edge cases, the simplest thing that works, over-engineering, maintainability, "would I approve this PR?" (the staff-correctness lens + the root manual's engineering contracts).
- **Domain expert** — does it fit emisar's architecture + trust model? Load the touched project's `AGENTS.md`: portal → the Iron Laws (`/elixir-iron-review`); runner/mcp → the security posture; packs → the conventions. emisar is an AI-safe infra control plane — flag anything that bends the model.
- **Security engineer** — lead with the abuse case. **Mandatory — emisar IS a security product** (`/security-engineer`).

**Earned hats — add when the diff touches their surface (lean toward MORE coverage; this is the thorough review):**

| The diff touches… | Add |
|---|---|
| LiveView / HEEx / components (operator-facing) | **UX designer** (`/design-ux`) + **UI/design-frontend** (`/design-frontend`) |
| a new capability, scope, or user flow | **PM** (`/product-manager` — right thing? smallest slice?) |
| marketing site / positioning / docs that rank | **marketing/SEO** (`/content-seo`) + **design review** (`/design-review`) |
| pricing, plans, plan-gating, billing, or a sellable/demoable capability | **sales** (no skill — lens: does it answer a buyer objection? is it demoable? is the plan-gating right? does it help close/expand a deal?) |

## 3. Fan out — one Agent per hat, in a single parallel batch
Spawn them concurrently (one message, many `Agent` calls). Give each the ref + touched files and this brief:

> You are the **<hat>** reviewing change `<ref>`. Read `.claude/skills/<skill>/SKILL.md` (if one maps
> to your hat) and the touched files **in full** — plus their callers/tests for context, not just the
> diff hunks. Review **only** through the <hat> lens. Report findings as a list, each:
> `SEVERITY · file:line · issue · why it matters · concrete fix`. SEVERITY ∈ BLOCKER / MAJOR / MINOR / NIT.
> Be specific to this change; skip what's clean; don't invent findings to look thorough. Keep the list scannable: one entry per finding, no preamble or recap.
> **Do NOT edit code — review only.**

Tell the security + domain hats to lead with the abuse case / the exact law each finding breaks.

## 4. Synthesize (you, the parent — don't just concatenate)
- **Dedupe** overlaps (UX+UI, staff+domain flag the same thing — merge, keep the sharpest wording).
- **Rank** BLOCKER → MAJOR → MINOR → NIT. BLOCKER = ships the wrong thing, a security hole, data loss/leak, an Iron-Law violation, or a real correctness bug.
- **Resolve cross-hat conflicts explicitly** — PM wants it thin, security wants a gate: state the call + why.
- One-line **verdict**: SHIP / SHIP-AFTER-BLOCKERS / RETHINK.

## 5. Write the fix plan (the deliverable)
Turn the ranked, deduped findings into an ordered, actionable plan — blockers first, then by area/risk:

```
## Review board: <title>   —   verdict: <…>   (<N blockers, M major, K minor>)

Headline: <ship-ability + the one thing that matters most>

### Findings (ranked, deduped)
- BLOCKER [security · staff] lib/…:42 — <issue> → fix: <…>
- MAJOR  [ux] …

### Fix plan (ordered; blockers/riskiest first)
1. <fix> — <what + where> — closes: [security:1, staff:3] — <independent | needs #N>
2. …

### Hat notes (one line each)
staff: … · domain: … · security: … · ux: … · pm: … · sales: …
```

Keep it honest and short. If it's clean: **"SHIP — nothing blocking"** + the few suggestions worth the reader's time. Never manufacture findings to look thorough, never bury a real blocker in nits.

**Then offer to queue it:** the BLOCKER/MAJOR items become tasks in the touched project's `.agent/tasks/00_todo/` (via `coop tasks add`), so `coop loop` can drain the fixes to a ship-ready bar. Queue on the user's go — never silently.

## Relationship to the focused reviews
`/review-board` convenes them all; the single-lens tools are its building blocks and stay for fast, focused runs: `/elixir-iron-review` (laws), `/security-engineer`, `/debug-investigate` (failures), `/design-ux`, etc.

**Proportional in-loop self-review** of one item is the same skill, sized down: the standing hats only (plus the hats the diff plainly earns), hat reports sized to the one item, and the verdict without the queued fix plan. There is no separate lighter skill.