| name | pr-review |
| description | M3E開発でPR（Pull Request）のレビュー・マージ・事後処理を行うスキル。
pr-beta（PR作成）の対になるスキルで、マネージャー側のワークフローを担う。
以下の場面でトリガーする:
- 「/pr-review」「PRレビューして」「PR見て」「マージして」と言われたとき
- PR URLやPR番号が提示されたとき
- devM3E の Integrate フェーズでマージ判断が必要なとき
- 「PRどうなってる」「PR状況」と聞かれたとき
dev-beta ブランチ（統合ロール）で使うことを想定。部下ブランチから呼ばれた場合でも動作するが、マージ権限は統合ロールのみ。
|
pr-review — PR レビュー・マージ・事後処理
PR作成後のマネージャー側フロー全体を扱う。
PR受領 → 差分レビュー → 検証 → 判定 → マージ → 事後処理
Step 1: PR の読み込み
PR番号 or URLが指定された場合:
gh pr view <number> --json title,body,headRefName,baseRefName,files,commits,state
gh pr diff <number>
PR番号が不明な場合:
gh pr list --base dev-beta --state open
読み取る情報:
- タイトル・概要
- ソースブランチ → ベースブランチ
- コミット一覧
- 変更ファイル一覧と差分
- 既存のレビューコメント
Step 2: レビュー
3つの観点で差分を評価する。devM3E の reviewer agent と同じ基準だが、PR文脈に特化。
2a. Spec整合チェック
変更が関連specに準拠しているか確認する。
- 変更ファイルから関連specを特定（
references/spec_index.md 参照）
- データモデル不変条件の維持
- Commandパターン（undo/redo）の維持
- scope/alias ルールへの適合
specを読む必要がある場合は docs/03_Spec/ から該当文書を読む。
2b. コード品質チェック
- 型安全性（不必要な
any、型アサーション）
- エラーハンドリング（fail-closed か）
- パフォーマンス懸念（O(n²)ループ、不要な再レンダリング）
- テストカバレッジ（新規コードにテストがあるか）
2c. 運用ルール準拠
- コミットメッセージが imperative 形式か
- daily note（
docs/daily/YYMMDD.md）が更新されているか
- Decision Pool に記録すべき設計判断が埋もれていないか
- ブランチ名がロールに合致しているか（visual→dev-visual 等）
Step 3: 検証（オプション）
差分の性質に応じて検証を実行する。
| 変更の性質 | 実行する検証 |
|---|
| TypeScript コード | npx tsc --noEmit |
| テスト関連 | npx vitest run |
| ビルド影響あり | npm run build |
| UI変更 | Playwright（該当テストがあれば） |
| ドキュメントのみ | スキップ |
検証を実行する場合は、PR のブランチをチェックアウトして行う:
gh pr checkout <number>
cd beta
npx tsc --noEmit && npx vitest run && npm run build
Step 4: 判定
レビュー結果を以下の形式でユーザーに報告する。
## PR #{number}: {title}
### 判定: ✅ approve / ⚠️ comment / ❌ request-changes
### 変更サマリー
{ファイル数}ファイル, +{追加行} -{削除行}
影響範囲: {beta/ | docs/ | scripts/ 等}
### レビュー結果
- [pass|fail] Spec整合: {detail}
- [pass|fail] コード品質: {detail}
- [pass|fail] 運用ルール: {detail}
### 検証結果
- tsc: pass/fail
- test: pass/fail ({n}/{total})
- build: pass/fail
### issue（あれば）
- [{severity}] {description}
### 推奨アクション
{マージしてよい / 修正が必要 / 要議論}
判定基準
| 判定 | 条件 |
|---|
| approve | issue なし or nit のみ。検証パス |
| comment | minor issue あるがマージをブロックしない |
| request-changes | major/critical issue あり。修正が必要 |
Step 5: マージ
ユーザーが承認した場合、マージを実行する。
git checkout dev-beta
gh pr merge <number> --merge
gh pr merge <number> --squash
マージ方法の選択
| 条件 | マージ方法 |
|---|
| コミット1-3件、各コミットが意味ある単位 | --merge（通常マージ） |
| コミット多数 or WIPコミット含む | --squash（1コミットに集約） |
| ユーザーが指定 | 指定に従う |
Step 6: 事後処理
マージ完了後に以下を実行する。
6a. Current Status 更新
統合ロールとして docs/00_Home/Current_Status.md を更新:
- 「最近の成果」に追加
- 「In Progress」から完了項目を除去
- 「Next 5」の更新（必要に応じて）
6b. Todo Pool 更新
docs/06_Operations/Todo_Pool.md の該当項目を done に変更。
6c. rebase 指示
マージ元のブランチ担当者（部下エージェント or ユーザー）に rebase を通知:
## 統合完了: PR #{number}
{title} を dev-beta にマージしました。
次の作業前に rebase してください:
git fetch origin dev-beta
git rebase origin/dev-beta
6d. ブランチ削除（オプション）
feature branch（ロールブランチ以外の一時ブランチ）の場合:
gh pr close <number> --delete-branch
ロールブランチ（dev-visual / dev-data / dev-data2 / dev-team）は永続ブランチなので削除しない。
Cowork 環境での制限
Coworkサンドボックスから gh コマンドや git push がブロックされる場合:
- レビュー（Step 1-4）はローカルの差分で実行可能
- マージ・事後処理のコマンドをユーザーに提示:
## ローカルで実行してください
gh pr merge {number} --merge
git checkout dev-beta && git pull origin dev-beta
- ユーザーがマージ完了を報告したら事後処理（6a-6d）を実行
pr-beta との連携
pr-beta（作成側） pr-review（レビュー側）
───────────────── ──────────────────────
状態チェック PR読み込み
差分分析 レビュー（spec/品質/運用）
タイトル・ボディ生成 →→→ 検証（tsc/test/build）
push & PR作成 判定 → ユーザーに報告
結果報告 マージ
事後処理（status/todo/rebase指示）
devM3E Core Loop における位置づけ:
- pr-beta: Execute 完了 → Integrate フェーズ前半（PR作成）
- pr-review: Integrate フェーズ後半（レビュー・マージ）→ Review フェーズへ
