Review Board

/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):

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 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 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. ≤300 words. 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: <2–3 sentences — 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), ≤250 words per hat, and the verdict without the queued fix plan. There is no separate lighter skill.