Check Dependabot

Dependabot PRに対して、依存ライブラリのバージョンアップに伴う破壊的変更や注意点を確認し、既存コードへの影響有無を判定・修正するスキルです。

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

!git fetch origin "$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch)" >/dev/null 2>&1 || true

（gh-compat.sh default-branch は git のローカル導出 → REST（GET repos/{o}/{r} の .default_branch）→ gh repo view の3段で解決する。クラウドセッションでは作業ツリーに refs/remotes/origin/HEAD が無く gh repo view --json も GraphQL ゲートで 403 になるため、REST 段が実質の解決手段になる。直接 gh repo view を呼ばない）

プリアンブル（! インライン実行）に失敗しうるコマンドを置かないこと: プリアンブルのコマンドが失敗すると、セッションはモデル未起動のまま何も出力せず exit 0 で終了し、ワーカーが空振り実行を延々と繰り返す。プリアンブルには || true で非致命化したコマンドだけを置き、gh pr checkout のような失敗しうるコマンドは本文のステップ0で実行する。

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の check-dependabot ワーカー（dependencies ラベル）から自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-triage-scope の付与や triage-pr への引き継ぎを進める。処理が未完のままターンを終えると、修正コミット未 push のまま triage-pr が古い差分でトリアージしたり、破壊的変更の調査未完でマージ判定に進む状態壊れが起きる。

修正のスコープと報告の分量

• パターンAの修正はバージョンアップ起因の影響への対応だけに限定する。調査中に気づいた既存の問題・リファクタ・別依存の整理は行わず、最終報告に1行で挙げるだけにする（Dependabot PR に無関係な差分を混ぜると、triage-pr 以降のレビューがバージョンアップの妥当性を判定できなくなる）
• 最終報告は「出力」のフォーマットの実質だけを書く。CHANGELOGやログの貼り付け・同じ内容の言い換えを載せない

実行内容

ステップ0: PRブランチのcheckout

以下を実行してPRブランチをcheckoutする。

gh pr checkout $ARGUMENTS

（gh pr checkout はローカル作業ツリーへの checkout であり、リモート API では代替できないため gh のまま残す）

クラウド実行時は実行しない。 クラウドセッションはワーカーが --on-branch で指定した PR の head ブランチ上で開始しており、既に目的のブランチにいる（gh pr checkout は GraphQL 経由でもあり、クラウドでは 403 で失敗する）。ワーカーが起動プロンプトへ同じ趣旨の指示を入れているが、git rev-parse --abbrev-ref HEAD が既に対象PRの head ブランチを指している場合も同様に checkout を省略してよい。

このコマンドが失敗した場合（典型例: fatal: '<branch>' is already used by worktree at ... — PRブランチが別のworktreeでcheckout中）は、後続のステップに進まず、エラー出力をそのまま含めて「判定: エラー」で結果報告を行い終了する。コード修正・push・ラベル操作は行わない（ブロッカー解消後のポーリングで自動的に再実行される）。

ステップ1: 対象PR情報の取得

GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

gh pr view $ARGUMENTS --json number,title,body,headRefName

PRのタイトル・bodyから、ライブラリ名（パッケージ名）・変更前のバージョン（from）・変更後のバージョン（to）・エコシステム（npm / pip / go modules / GitHub Actions など）を抽出する。

Dependabotの標準タイトル形式: Bump <package> from <old-version> to <new-version>

複数パッケージの更新（grouped update）の場合は、PR bodyから各パッケージの更新情報を全て抽出する。

ステップ2: 変更差分の取得

対象ライブラリの変更差分を、以下の優先順位で取得する。

2-1. PR bodyのrelease notes / changelog

Dependabot PRのbodyには多くの場合リリースノートとchangelogのサマリーが含まれるため、まずこれを確認する。

2-2. CHANGELOG / Release Notes（GitHub）

PR bodyに十分な情報がない、または破壊的変更の詳細確認が必要な場合は、GitHub上のCHANGELOGやReleasesを直接取得する。

tag_name は文字列であり、SemVerの大小関係と単純な文字列比較（>= / <=）の結果は一致しない（例: 文字列比較では "2.10.0" < "2.9.0" と判定される）。そのため範囲判定には sort -V（バージョンソート）を用いる。

# リポジトリの全releaseを取得
gh api repos/<owner>/<repo>/releases --jq '.[] | {tag_name, body}' > /tmp/releases.json

# from/to のtag_nameを "v" プレフィックス込みで正規化した上で、
# sort -V で範囲内（from超 〜 to以下）のtag_nameのみ抽出する例:
FROM="<from>"
TO="<to>"

# 各releaseのtag_nameがfromより大きくtoの範囲以下かを sort -V で判定
jq -r '.tag_name' /tmp/releases.json | while read -r TAG; do
  NORM_TAG="${TAG#v}"
  NORM_FROM="${FROM#v}"
  NORM_TO="${TO#v}"

  # NORM_FROM < NORM_TAG <= NORM_TO を sort -V で判定
  LOWER=$(printf '%s\n%s\n' "$NORM_FROM" "$NORM_TAG" | sort -V | head -1)
  UPPER=$(printf '%s\n%s\n' "$NORM_TAG" "$NORM_TO" | sort -V | head -1)

  if [ "$LOWER" = "$NORM_FROM" ] && [ "$NORM_TAG" != "$NORM_FROM" ] && [ "$UPPER" = "$NORM_TAG" ]; then
    echo "$TAG"
  fi
done

# 対象tag_nameが判明したら、そのbodyのみをreleases.jsonから取り出す
jq --arg tag "<対象tag_name>" '.[] | select(.tag_name == $tag) | {tag_name, body}' /tmp/releases.json

# CHANGELOGファイルを直接取得
gh api repos/<owner>/<repo>/contents/CHANGELOG.md --jq '.content' | base64 -d

2-3. context7 MCP

上記で十分な情報が得られない場合、または公式ドキュメントのマイグレーションガイドを確認したい場合に使用する。

# ライブラリIDの解決
mcp__plugin_claude-task-worker_context7__resolve-library-id
  libraryName: "<ライブラリ名>"

# マイグレーションガイドや破壊的変更に関するドキュメント取得
mcp__plugin_claude-task-worker_context7__query-docs
  context7CompatibleLibraryID: "<resolve-library-idで取得したID>"
  topic: "migration breaking changes <from> to <to>"

ステップ3: 影響範囲の分析

取得した変更差分をもとに、以下の観点でリポジトリ内コードへの影響を確認する。

• 破壊的変更（Breaking Changes）: 削除・リネームされたAPI、シグネチャ変更、挙動変更
• 非推奨化（Deprecations）: 警告対象のAPI使用箇所
• デフォルト値の変更: 設定値やオプションのデフォルト変更
• ピア依存関係の変更: peerDependenciesやminimum version要件の変更
• 型定義の変更: TypeScriptの型変更による型エラーの可能性

破壊的変更や非推奨APIがある場合、Grepツールで対象のシンボル・関数・設定名を検索し、使用箇所があるかを確認する。

ステップ4: CIステータスの確認

GitHub MCP が使える場合は pull_request_read（method: get_status / get_check_runs）を使う。以下は MCP 利用不可時のフォールバック。

gh pr checks $ARGUMENTS

• 全てpass: そのままステップ5の判定へ進む
• fail / pending がある: failしているチェックの内容（ログ）を確認し、原因がバージョンアップに起因するかを判断する
  • バージョンアップ起因のfail: ステップ5でパターンA（修正）に進む
  • バージョンアップと無関係なfail（flaky、外部要因など）: その旨を報告し、マージはせず処理を終了する
  • pending: 完了を待ってから再確認する

ステップ5: 修正要否の判定

修正が必要

• 破壊的変更の影響を受けるコードがリポジトリ内に存在する
• 型エラー・ビルドエラー・テスト失敗を引き起こす変更がある
• 非推奨APIの使用でCIがfailする可能性がある
• デフォルト値の変更により既存の挙動が変わる
• CIチェックがバージョンアップ起因でfailしている

修正不要

• 影響を受けるコードがリポジトリ内に存在しない
• パッチ/マイナーアップデートで破壊的変更なし
• 変更内容が内部実装のみで公開APIに影響なし
• CIチェックが全てpassしている

ステップ6: 修正の実施とpush

パターンA: 修正が必要な場合

1. 該当箇所をマイグレーションガイドに従って修正する
2. 必要に応じてビルド・Lint・型チェック・テストを実行して修正の妥当性を確認する
3. commit-push skillを用いてコミットとpushを行う

パターンB: 修正不要の場合

追加のコミットは行わず、CIチェックが全てpassしていることを再確認した上で、以下のコマンドでPRをマージする。判定だけで終了せず、必ずマージコマンドを実行すること。

gh pr merge $ARGUMENTS --merge --delete-branch

マージコマンドが失敗した場合は、エラー内容を記録して報告する。CIがpassしていない場合はマージを実行せず、状況を報告する。

パターンC: マージ不可能の場合

対象のバージョンはマージすることができない・するべきではないと判断する場合、PRをクローズする。例:

• 依存しているライブラリが最新のバージョンに対応していない
• 最新のバージョンにすることで、サービスの挙動が変わってしまう

注意事項

• 作業は必ず対象ブランチ上で行い、デフォルトブランチで作業は絶対に行わないこと
• ファイル編集などの作業を行う際は、pwdコマンドで現在のディレクトリを確認してから行うこと
  • 作業ディレクトリ: !pwd
• 複数パッケージを含むgrouped updateの場合は、すべてのパッケージについて個別に影響分析を行うこと
• Dependabot以外が作成したPRには使用しないこと

出力

処理結果として以下を報告する：

• 対象PR: PR番号とタイトル
• 対象ライブラリ: ライブラリ名とバージョン（from → to）
• 破壊的変更の有無: あり / なし（概要）
• CIステータス: 全pass / fail（原因） / pending
• 判定: パターンA（修正あり） / パターンB（マージ済み） / エラー
• 修正内容: 修正した場合はその内容（パターンAのみ）