review-pr
Review PR
Two verdicts, kept apart: spec (does the diff do what the sub-issue says?) and quality (is it code the repo wants to keep?). A PR can pass one and fail the other; the fix goes back to the author either way. The reviewer never edits code.
This is the slice gate: one PR into an integration branch, one fresh reviewer. The PR that takes the integration branch to main gets review-panel instead.
Usage: /review-pr <pr# | PR URL>
Use the URL when the epic spans repos; gh pr view, gh pr diff and gh pr checkout all accept it.
1. Fresh eyes
If you are already that fresh reviewer (the sdd-reviewer agent, a cloud run, or any session that did not write the code), skip to step 2. Otherwise, if the harness has subagents, dispatch one fresh reviewer per PR with this skill and the PR number as its whole context (Claude Code: the sdd-reviewer agent from the plugin, or a general-purpose agent with read-only tools plus gh). The reviewer must not be the worker and must not inherit the orchestrator's conversation. Without subagents, do the review yourself but only after clearing context of the implementation.