fusion-dependency-review

依存関係のレビュー

依存関係更新 PR のための構造化されたレビュー ワークフローです。既存の PR での議論、多角的な分析、マージ操作の前にメンテナーが明示的に確認する、実行可能な判断を取り入れた一貫性のある調査メモを作成します。

使用する場合

依存関係の PR をレビューする必要があり、一貫性のある監査可能な判断プロセスを求める場合に使用します。

一般的なきっかけ：

• 「この依存関係の PR をレビューしてください」
• 「この依存関係の更新をマージすべきですか？」
• 「この Renovate／Dependabot の PR を確認してください」
• 「未解決の依存関係 PR の 1 つをレビューしてください」
• 「このライブラリの更新で何が変わりましたか？」
• 「この依存関係の更新を安全にマージできますか？」
• PR タイトルに依存関係更新のパターン（例：chore(deps):、fix(deps):、bump、update）が含まれている
• ユーザーが依存関係更新の PR URL を共有する

使用しない場合

• 機能 PR やアプリケーションコードのレビュー（標準的なコードレビューワークフローを使用してください）
• 依存関係の自動化やボットの設定
• ユーザーの明示的な確認なしでの承認／マージ
• 組織の依存関係ポリシーの決定

必要な入力

開始前に以下を収集します。

• リポジトリのオーナーと名前
• PR 番号または URL、またはパッケージ名、バージョン変更、変更されたファイル、CI ステータスを含む、コピーされた PR の概要
• 任意：具体的な懸念事項や重点的に確認する領域

必要な情報が不足している場合は、references/questions.md にある簡潔な確認質問をしてください。

PR の対象が指定されていない、または曖昧な場合：

• 対象の PR を特定するために必要な最小限の追加質問だけをしてください。
• リポジトリのコンテキストが分かっている場合は、GitHub MCP を使って可能性のあるオープンな依存関係 PR を一覧表示し、ユーザーに選んでもらってください。
• 候補は簡潔にまとめてください。可能な場合は、PR 番号、タイトル、依存関係／パッケージのヒント、作成者、CI の状態を含めます。

利用可能な場合は、PR から以下を自動抽出します。

• 更新対象のパッケージとバージョン範囲（変更前 → 変更後）
• 変更履歴／リリースノートの URL
• CI の状態
• 変更されたファイルと依存関係のエコシステム
• 既存の PR のトップレベルコメント、レビューコメント、未解決スレッドの状態

手順

推奨されるアドバイザーのオーケストレーション

ランタイムがスキル内アドバイザーに対応している場合は、単一の長い直線的な処理ではなく、以下の実行形式を優先してください。

1. PR の対象が指定されていない、または曖昧な場合は、レビュー対象を 1 つの明確な依存関係 PR に絞るため、最初に agents/target-pr-advisor.md を実行します。
2. agents/research-advisor.md を実行し、PR のコンテキスト、既存の議論、ソース一覧、調査メモを整理します。
3. 同じ整理済みの入力を使って、以下の観点別アドバイザーを並列に実行します。

• agents/security-advisor.md
• agents/code-quality-advisor.md
• agents/impact-advisor.md

4. 調査結果と各観点の出力を agents/verdict-advisor.md に引き継ぎ、推奨事項、確信度、準備状況、引き継ぎ、確認を求める文面を作成します。
5. 受け入れられた次のステップで PR のパッチ適用、リベース、競合解決、またはマージ準備作業が必要な場合に限り、agents/source-control-advisor.md に引き継ぎます。

各観点のアドバイザーは、範囲を絞り、互いに独立して実行してください。親スキルは統一されたレビューを担い、アドバイザー間の意見の相違を早い段階で平坦化せず、そのまま保持してください。

ワークフローの概要

1. agents/target-pr-advisor.md と references/questions.md の簡潔な質問を使って、対象の PR を特定します。
2. agents/research-advisor.md、assets/review-tracker.md、assets/research-template.md を使ってコンテキストを収集し、共有エビデンスパケットを作成します。
3. 同じ整理済みの調査パケットを使って、agents/security-advisor.md、agents/code-quality-advisor.md、agents/impact-advisor.md を並列に実行します。
4. agents/verdict-advisor.md を使って、推奨事項、確信度、準備状況、フォローアップ、メンテナーへの明示的な確認依頼を作成します。
5. 判断が受け入れられ、ブランチ作業が必要な場合に限り、agents/source-control-advisor.md を使用します。
6. ライブ PR に関する詳細な契約（対象の選択、チェックポイントコメント、判断ゲート、引き継ぎのタイミング）については、references/instructions.md に従ってください。

アセット

• assets/research-template.md：変更概要、破壊的変更、既知の問題、情報源をまとめる調査コメントの構成
• assets/verdict-template.md：各観点の評価、推奨事項、確信度、準備状況、フォローアップ項目をまとめる判断の構成
• assets/review-tracker.md：コンテキスト、検証、各観点の結果、引き継ぎの判断を管理する作業チェックリストおよびトラッカー

参考資料

• references/instructions.md：対象の選定、進行中の PR のチェックポイント、判断の順序に関する詳細な実行手順
• references/questions.md：対象の依存関係 PR の選定とレビュー範囲の決定に必要な、簡潔なフォローアップ質問

アドバイザー

• agents/target-pr-advisor.md：レビュー対象となる依存関係 PR を特定するか、ユーザーが選択できる候補の一覧を返します
• agents/research-advisor.md：最初の確認を担当し、後続のすべてのアドバイザーが共有する証拠資料を作成します
• agents/security-advisor.md：並行して観点別の確認を行い、セキュリティ態勢と攻撃対象領域の変更を確認します
• agents/code-quality-advisor.md：並行して観点別の確認を行い、上流の安定性、リグレッション、API の乖離を確認します
• agents/impact-advisor.md：並行して観点別の確認を行い、リポジトリへの影響範囲、CI、フォローアップ作業を確認します
• agents/verdict-advisor.md：連携した統合確認を行い、調査結果と各観点の出力をひとつの判断にまとめます
• agents/source-control-advisor.md：パッチの適用が必要な場合に限り、最終確認を行い、リベース、同期、検証の再実行、プッシュの安全性を扱います

補助アドバイザーを利用できない場合は、同じ手順をインラインで実行してください。まず調査を行い、次に各観点を確認し、その後に判断をまとめます。ソース管理の確認は、変更が必要な場合に限り最後に行います。

出力要件

PR の対象が未確定の場合は、次の内容を返してください。

• 進行中の PR を検索できる場合は、依存関係 PR の候補を簡潔に一覧表示
• ユーザーが正しい PR を選択するために必要な、最小限のフォローアップ質問
• 明示的なステータス：Awaiting user PR selection

PR の対象が確定している場合は、次の内容を含む構造化されたレビューを返してください。

• パッケージ名、バージョンの変更、更新の種類
• 既存の PR の議論の概要（トップレベルのコメント、レビューコメントの論点、未解決の懸念事項）
• 調査の概要（変更履歴の要点、破壊的変更、既知の問題）
• 根拠を示したセキュリティ評価
• 根拠を示したコード品質の評価
• 根拠を示した影響評価
• 判断：推奨事項、理由、確信度、準備状況、フォローアップ項目
• フォローアップ作業を追跡対象の Issue にする場合の引き継ぎの推奨事項
• メンテナーへの明示的なアクションの提示

安全性と制約

• このスキルは変更を加える可能性があります。指示が競合する場合は、インラインのガイダンスよりもリポジトリ内のワークフロー指示を優先してください。

次のことは決して行わないでください。

• ユーザーから明示的な確認を得ずに、依存関係の PR をマージまたは承認する
• Dependabot または Renovate の PR ブランチにベースブランチをマージして、マージコミットを作成する
• 依存関係の PR が複数あり、どれをレビューすべきか判断できない場合に、推測で選ぶ
• 公開中の PR について、調査チェックポイントのコメントや最終判定のコメントを省略する
• 既存のレビュアーの懸念が都合の悪いもの、または重複するものだからという理由で無視する
• 実際のステータスを確認せずに、CI が成功した、またはセキュリティ上の問題がないと主張する
• コメントやログでシークレットやトークンを公開する
• 都合を優先してセキュリティ上の懸念を退ける
• ソースで確認できない変更履歴やバージョン情報を捏造する

必ず次のことを行ってください。

• 対象の PR が指定されていない、または曖昧な場合は、必要最小限の追加質問をする
• 各評価の根拠（変更履歴、CVE、CI ステータスへのリンク）を示す
• 技術的な推奨事項、根拠の確度、機械的なマージ準備状況をそれぞれ独立して評価する
• 保留中のチェックや必須の承認は、技術的な保留理由ではなく、準備状況を判断するゲートとして扱う
• メジャーアップデートには明示的な互換性の根拠を求める。ただし、セマンティックバージョニング上のカテゴリだけを理由に確度を低く評価しない
• リポジトリの情報はあるものの対象の PR が指定されていない場合は、ユーザーが選べるよう依存関係の PR 候補を列挙する
• 公開中の PR を分析する前に、GitHub MCP を使って既存の PR コメントとレビューのスレッドを取得する
• 各アドバイザーが同じ事実を再調査するのではなく、共通の調査パケットをアドバイザー間で再利用する。これには PR のメタデータ、変更ファイル、CI ステータス、既存の議論が含まれる
• 各アドバイザーが PR コメントやレビューのスレッドを個別に再取得しない。調査担当アドバイザーが事前に取得したデータを、すべての観点担当アドバイザーに渡す
• 実行環境が対応している場合は観点ごとの分析を並列に行い、すべての結果が揃ってから統合する
• 公開中の PR では、ブランチに変更を加える前に、調査チェックポイントのコメントを PR に投稿する
• 公開中の PR では、承認またはマージの前に、最終判定のコメントを PR に投稿する
• PR にパッチを適用する前に、ブランチ同期やリベースの必要性を明示する
• 更新が必要な場合は、依存関係の PR ブランチを最新のベースブランチにリベースする。ベースブランチを PR ブランチにマージしない
• フォローアップ作業を明示し、レビューコメントに埋もれさせない
• 最終的な決定権はメンテナーにあることを尊重する
• レビュー結果を、一貫性があり、繰り返し利用できる構成にする