# Review Board > 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. - Skill: `andrewdryga/review-board` (Agent Skill) - Install (CLI): `npx skillmds@latest add andrewdryga/review-board` - Raw SKILL.md: https://api.skillmd.com/api/skills/andrewdryga/review-board/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: AndrewDryga (https://skillmd.com/u/andrewdryga) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/andrewdryga/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 ` / `git diff ^..`. - **a range** (`a..b`, `a...b`, `HEAD~3..HEAD`) → `git diff `. - **a branch / ref** (`feat-x`, a tag) → its diff vs the base: `git diff main...`. - **a PR number** (`123` / `#123`) → `gh pr view --json title,body,files` + `gh pr diff ` (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 **** reviewing change ``. Read `.claude/skills//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: — 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.