name: deps-update model: inherit description: "Dependabot が作成した依存更新 PR（security updates / version updates）と，PR が付かない Dependabot alerts をまとめて処理する．メジャー更新でない・競合なし・CI 緑（またはローカル検証緑）のゲートを満たす PR だけを gh pr merge で main に取り込み，メジャー更新・CI 赤・修正版なしの alert 等は影響分析と推奨対応を添えて台帳と PR コメントに報告する．ユーザーが明示的に起動した時のみ実行する（/loop でのラップ可）．" argument-hint: "merge|report（省略時 merge） PR 番号…（省略時は全 Dependabot PR）"

あなたは依存更新（Dependabot）処理の司令塔です． /setup で有効化した Dependabot alerts / security updates と，.github/dependabot.yml による version updates が作る PR・alert を，「安全なものは取り込み，判断が要るものは材料を揃えて報告する」ために起動されました． 実際の gh 操作・検証・マージ・台帳更新は ops-runner エージェント（軽量モデル）に，個別の影響分析は deps-analyst エージェント に委譲し，あなたは振り分けと完了報告に徹します（使用量節約のため，収集・検証・投稿を自分では行わない）．

不変条件 (Invariants)

全文は本スキルの reference.md（.claude/skills/deps-update/reference.md）冒頭の「不変条件」にある．委譲する全エージェントのプロンプトに「reference.md の不変条件を読み厳守すること」を必ず含める．あなた自身が振り分けで守るべき要点:

• 触るのは Dependabot（author app/dependabot）の open PR だけ
• メジャー更新（0.x マイナー・unknown 含む）は自動マージしない．検証（CI 緑またはローカル検証）無しにマージしない
• Dependabot PR を close しない．@dependabot ignore は人間の決定（推奨として提示するだけ）
• ユーザーが起動した時だけ動く（Claude が自発的に本スキルを呼んではならない．/loop /deps-update でのラップはユーザー起動とみなす）

引数 (Arguments)

$ARGUMENTS を次のように解釈する:

• 先頭トークンが report なら報告のみモード（マージも PR コメントもしない．分析結果を完了報告と台帳に書くだけ）．merge または省略なら通常モード（ゲートを満たすものをマージし，残りを報告する）
• 残りのトークンに #12 / 12 形式の番号があれば，その PR だけを対象にする（省略時は open な Dependabot PR すべて）

フェーズ 1: 収集・分類 (Collect & Classify)

ops-runner エージェントを起動し，プロンプトに以下を含める:

• 手順書: reference.md の「不変条件」と「実行手順 A: セットアップと収集」を読んで従うこと
• 対象 PR 番号の指定（あれば）

返ってくるもの: 前提状態（Dependabot 設定・CI の有無・検証スイート・開始ブランチ）・分類付き PR 一覧（規模・スコープ・種別・状態・CI 状況）・alert 一覧・台帳の既出／スキップ情報．

• 作業ツリーが汚れている・gh 未認証・リモートが GitHub でない等の停止報告が来たら，処理を開始せずユーザーに伝えて終了する
• Dependabot 設定が無効・dependabot.yml 不存在なら処理は続け，完了報告で /setup の「GitHub リポジトリのセキュリティ設定」「依存バージョン更新の設定」を案内する

フェーズ 2: 振り分け (Route)

フェーズ 1 の結果を判定表で振り分ける．deps-update-skip.md 該当は除外（件数だけ完了報告へ），台帳既出の報告項目は再分析しない．

• マージ候補（判定「マージ」の見込み）→ フェーズ 3．security update → パッチ → マイナー の順に並べる（security update もゲートは緩めない．グループ PR は全メンバーの最大規模で判定する）
• 分析行き（「報告（分析付き）」・CI 赤・依存以外のファイル変更を含む PR）と PR が付かない alert → フェーズ 4
• 競合（CONFLICTING）・BEHIND（CI あり） → フェーズ 3 の委譲に「@dependabot rebase をコメントして今回は見送り」として含める（台帳には書かず，完了報告で「次回再試行」として伝える）
• report モード → フェーズ 3 を実行せず，マージ候補は「マージ可（未実行）」として完了報告と台帳に回す

フェーズ 3: 検証・マージ (Verify & Merge)

マージ候補と rebase 依頼をまとめて 1 体の ops-runner エージェントに委譲する．プロンプトに含める:

• 手順書: reference.md の「不変条件」と「実行手順 B: 検証とマージ」を読んで従うこと
• 対象 PR の一覧（処理順・各 PR の検証方法: CI 待ち / ローカル検証 / rebase 依頼のみ）
• 各 PR のマージ条件（判定表から機械的に導いて明示する．ops-runner に判定表を解釈させない）: patch → 到達 Tier が A または B なら可，minor → Tier A のみ可．Tier の定義: A＝CI 全緑またはローカル検証（テスト含む）全緑，B＝テストが無い／特定できないが依存インストールとビルド／型チェックは通る，C＝検証不能

検証が赤・Tier 不足・検証不能になった PR はマージされずに戻ってくるので，フェーズ 4 の分析対象に加える．

フェーズ 4: 影響分析 (Analyze)

分析行きの各項目について deps-analyst エージェントを 1 件 1 体で起動する（項目は互いに独立なので並列に起動してよい）．プロンプトに含める:

• 対象 PR / alert の収集データ（フェーズ 1・3 の結果から該当分．CI 赤の PR は失敗したチェックの要約も）
• 手順書: reference.md の「不変条件」「メジャー更新の影響分析」「PR コメントの書式」を読んで従うこと

返ってきた分析（破壊的変更・影響箇所・推奨）に不足があれば追加調査を指示する．

フェーズ 5: 記録・コメント (Record)

ops-runner エージェントを起動し，以下を委譲する:

• reference.md の「台帳の書式」に従い，フェーズ 4 の分析結果を deps-update-report.md に追記する（既出は再記録しない．フェーズ 3 のマージ結果は実行手順 B 内で deps-update-merged.md に追記済み）
• 通常モードでは，分析済み PR へ「PR コメントの書式」でコメントを投稿する（<!-- deps-update --> マーカーが既にある PR には再投稿しない）．report モードでは投稿しない

フェーズ 6: 完了報告 (Report)

ユーザーに以下を報告する（台帳を根拠にする）:

• モード（merge / report）と対象 PR 数，Dependabot 設定の状態（無効なら /setup の該当手順を案内）
• マージした PR: 番号・パッケージと版・種別（security / version）・規模・検証 Tier（CI / ローカル / ビルドのみ）．人間が行うべき動作確認があれば添える（例: UI ライブラリの更新は実機で表示確認）
• ⚠ 判断待ち（要人間対応）: メジャー更新（影響分析・推奨対応付き）／CI 赤／修正版なし alert／Dependabot が PR を作れなかった alert．security 由来のものは ⚠ 優先 を付けて上に並べる
• 見送り: 競合で @dependabot rebase を依頼したもの，CI 待ちのもの（次回再試行），deps-update-skip.md によるスキップ件数
• 次のアクション: 判断待ちの各項目について「PR をそのままマージ」「/implement で追従してからマージ」「@dependabot ignore this major version で見送り（人間がコメント）」のどれを推奨するか
• 後片付け: フェーズ 3 の報告から，開始ブランチへの復帰と作業ツリーがクリーンであることを確認して結果を含める

team モードでは，マージした PR の一覧をチームに周知するよう促す（全員が git pull する．GUIDE_03）．

/loop との併用 (Use with /loop)

Dependabot は週 1 回（dependabot.yml の interval）まとめて PR を作るため，単発実行で十分なことが多い．放置中に取り込みたい場合は /loop 1d /deps-update のように日次でラップしてよい．対象が無い回は収集だけで即終了するので空回りのコストは小さいが，2 回連続で「マージ 0・新規報告 0」なら /loop を終了してよい．

停止条件 (Stop Conditions)

• 作業ツリーがクリーンでない／gh 未認証／リモートが GitHub でない → フェーズ 1 の停止報告を受けて，開始せずに報告
• ローカル検証中にコンフリクト・環境エラーで検証が成立しない → その PR は Tier C として分析行きに回し，他の PR の処理は続ける
• gh pr merge がリポジトリ側の制約で失敗（ブランチ保護・必須レビュー・必須チェック未完了・権限不足） → その PR は報告に回し，失敗理由を伝える．team モードで「他メンバー Approve 必須」のブランチ保護が効いている場合は，本スキルはマージ可と判定した PR の一覧を提示するにとどめる
• gh pr merge が auto mode の分類器にブロックされた（コマンドが実行される前に遮断され，gh の出力が返らない） → 環境側の制約であって，リポジトリ設定の問題ではない（ブランチ保護と混同して報告しない）．.claude/settings.json の permissions.allow に Bash(gh pr merge:*) があるか確認し，無ければ「ユーザーが手で追加してセッションを再起動する必要がある」と報告する（Claude 自身は permissions を編集できず，設定変更はセッション再起動後に反映される）．該当 PR は「マージ可と判定したが未実行」として報告し，main への直接 push 等でマージを迂回しない
  • ※ allow ルールの追加は settings.json の手編集のほか /permissions ダイアログからも行えるが，~/.claude/settings.json に autoMode.classifyAllShell: true があると狭い allow ルールも分類器に回るためこの対処は効かない（追加しても通らないときは該当設定の有無を確認する）