コンテンツにスキップ
soloscrum docs

/review

/review は soloscrum の quality gate です。/develop が開いた draft PR を読み、DoD と Issue の AC を 1 つずつ検証し、CodeRabbit と multi-agent review pipeline を走らせ、見つかった finding を 1 件ずつ判断し、Pass / Pass with follow-ups / Fail のいずれかの verdict を投稿します。Pass の場合は Subtask を done に進め、CI green を待ち、PR を ready に昇格させ、gh pr merge のコマンドを提示します。merge そのものは 常に ユーザのゲートです。

使い方

Section titled “使い方”
Terminal window
/review <pr-url|pr-number or figma-url>
  • PR の review なら PR URL か番号を渡します
  • type:design-ui Subtask の design-fidelity review なら Figma URL を渡します

処理の流れ

Section titled “処理の流れ”
  1. DoD 検証。 DoD の全項目を確認します。PR 本文に closing keyword (Closes #N) が入っていること、lint がクリーン、必要なテストが揃っている、AC が満たされている、をそれぞれ確認します。
  2. AC 検証。 親 Issue の AC チェックボックスを、diff とビルドの動作に照らして 1 件ずつ確認します。
  3. CodeRabbit 実行。 CodeRabbit CLI を diff に対して走らせます。「No findings」が返ってきても multi-agent パスはスキップしません — PR が小さい / docs だけ、という理由で multi-agent を飛ばすのは anti-pattern です。
  4. multi-agent review。 専門観点を持つ複数の agent (security / accessibility / performance など) が diff を並列で review します。confidence 80 以上の finding を集約します。
  5. finding ごとの判断。 プレフィルタを通った各 finding に対し、fix するか、理由を明記して skip するかを 1 件ずつ決めます。severity は情報用であり、skip 理由にはなりません。
  6. verdict。 Pass / Pass with follow-ups / Fail を構造化された PR コメントとして投稿します。このコメントが正式な記録です。
  7. verdict 後のアクション。 Pass の場合: PR を approve (gh pr review --approve、後述の self-approve refusal の注意あり) し、Subtask を done に進め、CI green を待ち、PR を ready に昇格 (gh pr ready) させ、merge コマンドを提示します。Fail の場合: finding ごとのフィードバックを投稿し、Subtask を in-progress に戻し、PR は draft のまま残します。

典型的な流れ

Section titled “典型的な流れ”

/develop を終え、https://github.com/<owner>/<repo>/pull/123 のような draft PR の URL を持っています。/review https://github.com/<owner>/<repo>/pull/123 を実行します。Review agent は DoD のチェックリストを順に確認し、AC を diff と突き合わせ、CodeRabbit を走らせ、multi-agent pipeline を回し、検出された finding を 1 件ずつ判断します。各 finding は「commit X で修正済み」または「skip 理由: 〜」のいずれかに収束します。「あとで考える」というオプションはありません — verdict はすべての finding を決着させた結果です。

Pass の場合、agent は gh pr review --approve を実行します (solo-dev では self-approve refusal で失敗する — 想定内)。続いて Subtask を done に進め、skills/soloscrum-tracker-github-wait-for-pr-checks/scripts/wait-for-pr-checks.sh <pr> で CI を待ち、gh pr ready を走らせます。待っている間に CI が red になれば Pass はさかのぼって Fail に格下げです。最後に merge コマンド — gh pr merge <pr-number> --squash などリポジトリの方針に合わせたもの — を提示して停止します。gh pr merge を実行するのはユーザの仕事であり、agent の仕事ではありません。verdict がどれだけ綺麗でも例外はありません。

Fail の場合、agent は finding ごとのフィードバックを PR にコメントし、Subtask state を in-progress に戻し、PR は draft のままにします。「まだ作業が必要」というシグナルを外部から見える形で残すためです。ユーザは /develop を再実行して finding に対応し、/review をやり直します。

self-approve refusal について

Section titled “self-approve refusal について”

GitHub は PR の作成者本人による approve を許可していません。soloscrum が前提とする solo-dev では gh pr review --approve が Can not approve your own pull request で失敗します。これは Fail ではありません。verdict コメントこそが Pass の正式な記録で、API 側の approve は solo-dev では構造上発生し得ない重複シグナルです。try-and-fall-through のパターンで処理します。

Terminal window
gh pr review --approve "$PR_URL" \
  || echo "approve skipped (likely self-approve refusal); verdict comment is the formal Pass record"

verdict 後の一連のアクション — tracker の → done、CI 待機、gh pr ready、merge コマンドの提示 — はそのまま続行します。

出力

Section titled “出力”
  • PR 上に構造化された verdict コメント (DoD チェックリスト、AC チェックリスト、finding ごとの判断、verdict)
  • Pass の場合: Subtask state が done、PR が ready、gh pr merge のコマンドを提示
  • Fail の場合: finding ごとのフィードバック、Subtask は in-progress に戻り、PR は draft のまま

Issue 自体は /review で close されません。close するのは PR の merge であり、引き金は PR 本文の Closes #N キーワードと GitHub の auto-close です。詳しくは PR ライフサイクル を参照してください。

参考

Section titled “参考”