pr-review

PR レビューワークフロー

適切な AQE のスコープ境界を守り、明確なコミュニケーションと実行可能なフィードバックを提供して、プルリクエストをレビューします。

引数

• <pr-number> — レビューする GitHub PR の番号です。省略された場合は、ユーザーに確認します。

手順

1. 差分全体を読む

gh pr diff <pr-number>
gh pr view <pr-number>

差分全体と PR の説明を読みます。流し読みせず、変更されたファイルをすべて確認します。

2. スコープを確認する

• AQE/QE スキルのみを分析します（Claude Flow プラットフォームスキルは対象外です）。
• 対象外とするプラットフォームスキル：v3-, flow-nexus-, agentdb-, reasoningbank-, swarm-, github-, hive-mind-advanced, hooks-automation, iterative-loop, stream-chain, skill-builder, sparc-methodology, pair-programming, release, debug-loop
• PR がスキルに触れている場合、件数とスコープが想定（約82個の AQE スキル）と一致するか確認します。
• AQE に焦点を当てた PR にプラットフォームスキルの変更が混入している可能性があれば指摘します。

3. 変更内容を要約する

何が変わったのか、なぜ変わったのかをユーザーにわかりやすくまとめます。

• 実装の詳細ではなく、得られる成果に焦点を当てます。
• 専門用語を使いすぎないようにします。
• 箇条書きは3～5項目にまとめます。

4. 信頼度ティアを検証する

スキルに変更がある場合、trust_tier の割り当てを検証します。

• tier 3 = 評価用インフラ（evals/, schemas/, scripts/）がある
• tier 2 = テスト済みだが、評価フレームワークはない
• tier 1 = 未テスト
• 整合性に問題があれば指摘します（例：evals があるスキルに tier 2 が割り当てられている場合は tier 3 であるべきです）。

5. コード品質をレビューする

以下を確認します。

• ハードコードされたバージョン文字列
• 本番環境の安全性に関する懸念（アダプターの変更、破壊的変更）
• 新しいコードに対するテストカバレッジの不足
• セキュリティ上の問題（露出したシークレット、インジェクションのリスク）

6. レビューを投稿する

gh pr review <pr-number> --body "review comments"

コミュニケーションのルール

• 建設的で、実行につながるトーンを保ちます。
• 成果を重視し、何が問題なのかではなく、作成者が何をすべきかを伝えます。
• 細かなコメントを多数投稿するのではなく、関連するコメントをまとめます。
• 軽微な提案を添えて承認する場合は、REQUEST_CHANGES ではなく、コメント付きの APPROVE を使用します。