Command
/pr-review
classify → convene the board → consolidate
Review someone else's PR. Report a verdict. Do not change the code.
See it run
/pr-review runs, in order.How to run it
Run it in your harness
/pr-review <pr-number or PR url> [optional emphasis passed to every reviewer — e.g. "weight the schema change"]<angle brackets> = required · [square brackets] = optional
How it works
The diff is classified with the same flags as /ship-issue. Product-manager and principal-engineer always sit; the flags pull the rest. This command reports — it never edits the branch.
Classify
Read the diff and set the flags. Those flags are how the board is assembled — a role whose flag is off is not spawned.
No spawn yet — classification is the run.
Read CI
Note red checks as findings. This command does not repair them: you do not own the branch.
Still the run. It reports CI; it never repairs.
Board
Specialists review the pushed head in parallel. Because this is someone else's PR, security sits here when the flag is on — /shipmates-harden is not available.
Also sit when
architectnew subsystem, schema, or a change that crosses many modulesux-ui-designeron-screen UI — screens, flows, componentsart-directorrendered art (games, illustration), not app chromesdetthe plan asks for a specialist test reviewdevops-engineerpipeline, images, or how the project shipstechnical-writerdocumented behaviour or a public API/CLIsecurity-engineerauth, secrets, crypto, or untrusted inputperformance-engineera claimed perf win, or a known hot pathsite-reliability-engineerruntime behaviour, failure handling, or rolloutdata-scientistthe deliverable is an analysis or a model
Verdict
One ranked accept-or-block, with reasons attributed to the role that raised them.
You synthesise — no extra spawn.
When to use
- A pull request needs an adversarial pass and you do not own the branch.
- You are delivering the work? /ship-issue, not this.
The skill
The installer ships the full skill — stages, gates, config — from commands/pr-review.md.