/review
/review is the quality gate. It reads the draft PR opened by /develop, verifies the DoD and every Issue AC, runs CodeRabbit and a multi-agent review pipeline, decides each finding individually, and posts a Pass / Pass with follow-ups / Fail verdict. On Pass it transitions the Subtask to done, waits for CI green, promotes the PR to ready, and surfaces the exact gh pr merge command. The merge itself is always your gate.
/review <pr-url|pr-number or figma-url>- For PR review, pass the PR URL or number.
- For design-fidelity review of a Figma file (
type:design-uiSubtasks), pass the Figma URL.
What happens
Section titled “What happens”- DoD verification. Every checklist item in the DoD is checked. The PR body must contain a closing keyword (
Closes #N); lint must be clean; tests must exist where applicable; AC must be satisfied. - AC verification. Every checkbox in the parent Issue’s AC is verified against the diff and the running build.
- CodeRabbit run. The CodeRabbit CLI runs against the diff. Even a “No findings” result still requires the multi-agent pass — skipping the multi-agent step because the PR is small or docs-only is a named anti-pattern.
- Multi-agent review. Specialist agents (security, accessibility, performance, etc.) review the diff in parallel. Findings with confidence ≥ 80 are consolidated.
- Per-finding decision. Each surviving finding is decided individually: fix it, or skip it with a stated reason. Severity is informational, not a skip reason.
- Verdict. Pass / Pass with follow-ups / Fail is posted as a structured PR comment. The verdict comment is the formal record.
- Post-verdict actions. On Pass: approve the PR (
gh pr review --approve, see the self-approve note below), transition the Subtask todone, wait for CI green, promote the PR to ready (gh pr ready), and surface the merge command. On Fail: post per-finding feedback, revert the Subtask toin-progress, leave the PR in draft.
Typical flow
Section titled “Typical flow”You finished /develop and have a draft PR URL like https://github.com/<owner>/<repo>/pull/123. You run /review https://github.com/<owner>/<repo>/pull/123. The Review agent walks the DoD checklist, ticks AC against the diff, runs CodeRabbit, runs the multi-agent pipeline, and decides every flagged finding. Each ends as either “fixed in commit X” or “skipped because
On Pass, the agent runs gh pr review --approve (fails with a self-approve refusal in solo-dev — expected). It transitions the Subtask to done, waits for CI via skills/soloscrum-tracker-github-wait-for-pr-checks/scripts/wait-for-pr-checks.sh <pr>, and runs gh pr ready. If CI goes red during the wait, the Pass retroactively downgrades to Fail. Finally, the agent surfaces the merge command — gh pr merge <pr-number> --squash or whatever the repo prefers — and stops. Running gh pr merge is your job, not the agent’s, regardless of how clean the verdict was.
On Fail, the agent posts per-finding feedback to the PR, reverts the Subtask state to in-progress, and leaves the PR in draft so the “needs more work” signal is externally visible. You run /develop again to address the findings, then re-run /review.
Self-approve refusal
Section titled “Self-approve refusal”GitHub does not let a PR’s author approve their own PR. In solo-dev — the default soloscrum is built around — gh pr review --approve fails with Can not approve your own pull request. This is not a Fail. The verdict comment posted on the PR is the formal Pass record; the API-side approval is a duplicate signal solo-dev structurally cannot produce. Use try-and-fall-through:
gh pr review --approve "$PR_URL" \ || echo "approve skipped (likely self-approve refusal); verdict comment is the formal Pass record"The post-verdict sequence — tracker → done, CI wait, gh pr ready, surfacing the merge command — runs anyway.
Output
Section titled “Output”- A structured verdict comment on the PR: DoD checklist, AC checklist, per-finding decisions, verdict.
- On Pass: Subtask state advanced to
done, PR promoted to ready, thegh pr mergecommand surfaced. - On Fail: per-finding feedback posted to the PR, Subtask reverted to
in-progress, PR left in draft.
The Issue itself is not closed by /review. Closure happens at merge time via the PR body’s Closes #N keyword and GitHub’s auto-close. See PR lifecycle.
See also
Section titled “See also”- Agents and responsibilities — Review is the only role that issues a Pass.
- PR lifecycle — autonomy contract, reversible vs irreversible, why merge is always your gate.
- Code review process — the per-finding decision rules and verdict mapping.
- DoD — the checklist
/reviewdecides against. - Previous:
/develop. - Canonical contract:
commands/review.md.