merge-dependabot-prs

Dependabot の PR をマージする

gh CLI を使って、Dependabot の未解決のプルリクエストをまとめてマージします。定期的な依存関係の更新ノイズは、すべての差分を人が確認しなくても反映できるよう、保守的なデフォルトフィルターを適用します。一方、ビルドを実際に壊す可能性のあるものは、人が確認できるよう保留します。

このスキルは、ユーザーが依頼した場合にのみ実行します。別の作業中に未解決の PR に気づいたからといって、便宜的にマージしてはいけません。マージは外部に影響し、元に戻すのも面倒なため、必ずユーザーから依頼された作業として実行します。

デフォルト設定

同じ依頼内でユーザーから別の指示がない限り、以下を適用します。

判断項目	デフォルト	理由
バージョン範囲	マイナーおよびパッチの更新のみ	メジャー更新には意図的な破壊的変更が含まれるため、人による確認が必要です。
保留するメジャー更新	評価するが、マージしない	「スキップ：メジャー」では、ユーザーは判断材料を得られません。このプロジェクトに関する簡潔なリスク評価を提示します。
CI ゲート	すべてのチェックが正常に完了していること	ビルドが成功していることだけが、更新の安全性を示す証拠です。保留中は未合格として扱い、チェックが一つもない場合は証拠がないものとします。
ワークフローの承認	必ず承認前に確認する	自動パイプラインによるコミットは、後続の実行で action_required を引き起こします。実行を承認するとリポジトリの権限でコードが実行されるため、ユーザーの確認なしに承認してはいけません。
古いブランチ	古いベースブランチでの成功は部分的な証拠	CI は、そのブランチの作成元コミットに対して実行されています。ベースブランチが更新されている場合、より小規模なテストスイートしか実行されていない可能性があり、出力にはそのことが示されません。
マージ方法	--rebase	履歴を直線的に保ち、依存関係の更新でマージコミットを作成しません。
ブランチのクリーンアップ	--delete-branch	Dependabot のブランチは使い捨てで、すぐに増えるためです。
リポジトリ	作業ディレクトリにあるリポジトリ	ユーザーが別のリポジトリを指定した場合は、--repo OWNER/REPO を渡します。
順序	PR 番号の古いものから、一つずつ	マージのたびにベースブランチが更新されるため、順番に処理すると失敗時の状況を把握しやすくなります。

ユーザーの指示がこれらのデフォルト設定より優先されます。よくある上書き指示とその意味は次のとおりです。

• 「メジャーも含めて」／「全部」→ バージョンフィルターを解除します。CI ゲートは引き続き適用します。
• 「パッチだけ」→ バージョンフィルターを厳しくします。
• 「チェックが失敗していても」／「CI を待たないで」→ CI ゲートを解除します（以下の注意事項を参照）。
• 「スカッシュして」／「マージコミットを使って」→ --rebase ではなく --squash または --merge を使います。
• 「ブランチを残して」→ --delete-branch を解除します。
• 「GitHub Actions のものだけ」／「npm だけ」→ 依存関係名と Dependabot のラベルで確認できるエコシステムで絞り込みます。
• 「#42 と #47 をマージして」→ 明示されたリストのみを対象にします。指示がない限り、デフォルトのゲートは引き続き適用します。
• 「マージだけして、メジャーの分析は不要」／「説明は省略して」→ ステップ 5 のリスク評価を省き、保留したメジャー更新は番号とバージョンのみ報告します。

マージによってメジャー更新を含める、失敗または保留中のチェックがある状態でマージする、あるいは --admin を使ってブランチ保護を回避するなど、安全ゲートを緩和する場合は、何がマージされるのかを明確に伝え、実行前に承認を得てください。ユーザーが緩和を依頼したことは、その選択肢を提示する理由にはなりますが、確認を省く理由にはなりません。こうしたマージは、事後に判明した場合の対応コストが特に高いためです。同様に、承認が必要なワークフロー（action_required）を承認すると、GitHub Actions ランナーで実行が開始されます。承認前に、どの PR とコミットが実行を引き起こすかを必ず伝え、ユーザーの確認を得てください。

ワークフロー

1. 事前確認

gh auth status

gh が見つからない場合、または認証されていない場合は、そこで停止してその旨を伝えます。以降のすべての処理で gh が必要です。

次に、使用する予定のマージ方法がリポジトリで許可されていることを確認します。

gh repo view --json nameWithOwner,rebaseMergeAllowed,squashMergeAllowed,mergeCommitAllowed

リベースマージが無効になっている場合、別の方法に黙って切り替えてはいけません。マージ戦略によって履歴に反映される内容が変わるため、許可されている方法のどれを使うかユーザーに尋ねます。

2. インベントリを作成して分類する

同梱のスクリプトを実行します。読み取り専用で、面倒な処理を一貫して行います。Dependabot の updated-dependencies コミットトレーラーを読み取り、トレーラーに update-type がない場合（よくあります）は「Bumps X from A to B」に記載されたバージョンを比較し、グループ化された PR のすべてのメンバーのうち最も大きな更新を採用し、チェックの集計結果を一語にまとめます。

python3 <skill-dir>/scripts/dependabot_prs.py            # current repo
python3 <skill-dir>/scripts/dependabot_prs.py --repo OWNER/REPO
python3 <skill-dir>/scripts/dependabot_prs.py --json     # same data, machine-readable

各行には、更新の種類（patch／minor／major／unknown）、チェックの状態（pass／failing／pending／none）、GitHub のマージ状態、PR がデフォルトポリシーを満たすかどうかが表示されます。デフォルトポリシーではスキップされる項目には、その理由も付記されます。

次の 4 つの分類は、機械的に適用するのではなく、判断が必要です。

• unknown の更新 — 通常は SHA で固定された GitHub Action で、比較できるバージョンがありません。minor と仮定するのは安全ではありません。デフォルトではスキップし、ユーザーに提示します。

• チェックが none — その PR にはリポジトリの CI がなく、更新が安全だという根拠がありません。ゲートが存在しないことは、ゲートを通過したことにはなりません。そのため、注意書き付きでマージするのではなく、スキップします。これらの PR を報告し、それでもマージしたい場合は、具体的な PR 番号を指定するようユーザーに伝えてください。一括マージを提案してはいけません。また、「Dependabot の PR をすべてマージする」という指示に含まれると見なしてはいけません。CI のないリポジトリこそ、問題のある一括マージが見過ごされる場所です。

  具体的な番号を指定した依頼が返ってきた場合（「#29 と #31 をマージして」など）、それがこのゲートで待っていた明示的な指示です。追加の確認は不要です。通常のデフォルト設定でマージします。

• 古いブランチでチェックが pass — 緑のチェックで証明されるのは、ブランチを切った時点のコミットに対する更新の安全性であり、現在のベースに対するものではありません。ブランチが放置されている間にベースが更新されていると、実行されたテストスイートは、現在のベースブランチ上のものより大幅に小さい可能性がありますが、CI の出力にはそのことが示されません。成功した実行では、実行時の合計数が報告されます。期待される合計数をすでに把握していない限り、その数は不足がないように見えます。これは部分的な根拠であり、承認を意味するものではありません。

  PR が 1、2 日以上オープンしている場合は必ず確認し、また、緑のチェックが根拠の大半を占める major 更新では必ず確認してください。

  branch=$(gh pr view <n> --json headRefName --jq .headRefName)
  git fetch origin "$branch"
  git merge-base --is-ancestor origin/main "origin/$branch" \
    && echo "based on current main" || echo "STALE — CI ran against an older base"
  

古くなっている場合は、2 つのツリーに実際に含まれている内容を比較します。多くの場合、テストファイルを確認すれば判断できます。

git ls-tree -r --name-only "origin/$branch" | grep -cE '\.test\.[jt]sx?$'
git ls-tree -r --name-only origin/main      | grep -cE '\.test\.[jt]sx?$'

ルートから glob でテストを収集するランナーを使うリポジトリは、特に影響を受けやすいものです。収集されるファイル数はブランチの経過時間に左右されるため、古いブランチではテスト対象が知らないうちに減ります。実例として、vitest の更新で CI が「33 passed (33)」と誇らしげに報告した一方、ブランチを切った後に 18 個のテストファイルが追加されていたため、ベースブランチには 51 個のテストファイルがあったケースがあります。

件数が異なる場合は、緑のチェックを根拠として引用するのではなく、計画にその旨を記載します。修正は簡単です。ブランチに Dependabot 以外のコミットがある場合（後述の「ブランチの再作成」を参照）を除き、自分で @dependabot recreate を投稿し、再作成させてから、新しいブランチの CI を確認します。差を埋めるために手動でリベースしてはいけません。

• action_required のチェック（承認待ちのワークフロー） — ワークフローの実行がトリガーされています（通常は、フォーマッター、ロックファイル生成ツール、移行ツールなど、自動パイプラインのステップが PR ブランチにコミットしたことが原因です）。その後の実行は GitHub によって action_required（経過時間 0 秒）に設定されます。これはテストの失敗ではありません。Bot／アクションのコミットがトリガーした実行にはメンテナーの承認が必要なため、テストスイートがまだ実行されていないだけです。

  ワークフローの実行を、ユーザーに知らせずに、または自動的に承認してはいけません。実行を承認すると、GitHub Actions ランナー上でリポジトリの権限を持つコードが実行されるため、ユーザーによる明示的な判断が必要です。トリガーとなったコミットと停止中のワークフロー実行を特定し、計画に示したうえで、承認する前に確認を求めてください（後述の承認ワークフローのセクションを参照）。

3. 何にも手を付ける前に計画を報告する

これから何をマージし、何をそのままにするのか、その理由も含めて、1〜2行で正確に伝えます。これにより、まとめて行うマージをレビューできるようになります。分類が間違っていれば、この時点で気づくことができ、手間もかかりません。

実際の Markdown 見出し（###）の下に、分類した箇条書きとして記載します。Markdown の表は使いません。スクリプトの表は自分用です。返答を読むのは、ターミナルや、表の表示が崩れやすいクライアントを使っている人かもしれません。崩れた表より、単純なリストのほうが適しています。太字のラベルではなく見出しを使い、読み手が項目をたどれるようにします。「マージ」と「保留」のような短い見出しの下に、各 PR を1行で記載します。番号、依存関係、バージョン範囲、判定を含めます。

その後、処理を進めます。「Dependabot の PR をすべてマージする」という明示的な指示は、フィルターを通過した PR 一式をマージする許可とみなします。確認のために停止するのは、ゲートを緩和した場合（上記）、計画が空の場合、または何か問題があるように見える場合だけです。ワークフローの実行に承認が必要なために保留となった PR がある場合は、その実行を承認してよいか確認します。影響を受けない、マージ可能な PR は引き続きマージしてかまいません。

4. 1件ずつマージする

gh pr merge <number> --rebase --delete-branch

現在のディレクトリ以外で作業する場合は、--repo OWNER/REPO を追加します。PR 番号の昇順でマージし、次の PR の処理を始める前に、毎回結果を確認します。

ここでは、順番に処理することが重要です。マージのたびにベースブランチが進むため、後続の PR が BEHIND になったり、まとめて処理している途中で競合し始めたりすることがあります。ブランチを最新状態に保つことがブランチ保護で必須となっているリポジトリでは、特にその傾向があり、まとめて処理した場合、最初の PR だけがマージに成功することもあります。これは想定内であり、計画の失敗ではありません。

まとめて処理している途中でマージに失敗した場合は、残りの処理を続け、失敗した PR を記録します。よくある原因は次のとおりです。

失敗	意味	対応
not mergeable: the merge commit cannot be created／競合	先行する PR のマージなどにより、ブランチの状態が変わりました	その旨を報告して次に進みます。コメントを書く前に、下記を確認してください
ベースブランチが最新ではない（ブランチ保護）	リポジトリでブランチを最新状態に保つ必要があります	同様に、報告して次に進みます
API が引き続き CLEAN と報告している PR での Pull request is not mergeable	GitHub のキャッシュされたマージ可能状態が古くなっています。このまとめ処理中に先行する PR がマージされ、ベースが更新された後、PR がまだ再評価されていません	1回だけ再試行します。同じエラーが出た場合は、ブランチの状態変化によるものとして扱います
保留中のチェックがある PR での Pull request is not mergeable	ベースの変更後に CI が再起動しました	完了を待つのではなく、オートマージを提案します：gh pr merge <n> --rebase --delete-branch --auto
action_required／ワークフローの承認が必要	パイプラインのコミットによって後続の実行が開始されましたが、承認待ちで停止しています	ユーザーに確認してから、gh api で承認し、完了まで監視します（下記参照）
レビューが必要	ブランチ保護で承認が必須になっています	その旨を報告します。依頼されていない限り、自分で承認したり --admin を使ったりしないでください

ブランチの再構築：リベースではなく再作成する

ベースブランチに変更があると、Dependabot は自身が作成したオープンな PR をリベースします。これはデフォルトの rebase-strategy です。そのため、バッチ処理の途中で通常の競合が発生した場合は、PR をもう一度確認する必要があると報告して、そこで止めるのが適切です。コメントを追加してもノイズが増えるだけで、何の役にも立ちません。リベースはもともと実行される予定だったからです。

自動処理が行われない、または不十分だと考える理由がある場合は、ブランチを後押しする必要があります。たとえば、古いベースに対してグリーンのチェックが実行されたほど古い PR（ステップ 2）や、以前のマージでリベースが行われるはずだったのに、その後も競合が残っている PR です。そのように判断したら、実際に対応してください。リベースを勧めるだけで、ユーザーにコマンドを入力させたままにしてはいけません。まず、誰がブランチにコミットしたかを確認してください。これによって、送信する内容が決まります。

gh pr view <n> --json commits --jq '[.commits[].authors[].login] | unique'

Dependabot のみ — 確認を求めず、自分で再作成を依頼します。

gh pr comment <n> --body "@dependabot recreate"

rebase ではなく recreate を送信してください。Dependabot 以外が変更していないブランチでは、再作成によって破棄されるものはありません。また、今日のベースに対して更新を一から再構築し、古いロックファイルを再生するのではなく再生成するため、古さと、リベースでは解消できない競合の両方を修正できます。概要には、どの PR に送信したかを記載してください。CI が再実行されるため、この実行中はマージできません。

Dependabot 以外が含まれる場合 — 何も送信しません。多くの場合、これはロックファイルの再生成やフォーマッターなど、PR にコミットを追加するワークフローのステップです。Dependabot がそのようなブランチのリベースを停止するのは、まさにその作業を上書きしないためです。そのため、@dependabot rebase を送信しても何も起こりません。@dependabot recreate は機能しますが、追加のコミットで行われた変更を破棄するため、判断はあなたではなくユーザーに委ねます。PR と追加の作成者を示し、リベースでは解決しないことを説明して、再作成するかどうかを尋ねてください。

Dependabot のブランチを手動でリベースしてはいけません。Dependabot がこれらのブランチを管理しています。手動でリベースすると、上記の「他の誰かがプッシュした」状態を自ら作り出し、後押ししようとしていた自動リベースが停止します。

ユーザーから依頼されていない限り、「整理」のために Dependabot の PR を閉じてはいけません。PR を閉じると、その更新の提案を Dependabot に停止させることになり、長期にわたって影響する判断となります。

パイプラインのコミットで停止したワークフローを承認する

ワークフローのステップ（Biome Migrate、Prettier、ロックファイルジェネレーターなど）が PR ブランチにコミットすると、GitHub Actions は後続のワークフローが再帰的に実行されたり、監視なしで実行されたりするのを防ぎます。その結果、後続のワークフロー実行（CI など）は conclusion: action_required と経過時間 0s でマークされます。

これはテストスイートの失敗やビルドの破損ではなく、チェックがまだ実行されていないだけです。ただし、GitHub Actions ランナーでのコード実行を承認するとリポジトリへのアクセスが許可されるため、ワークフローの実行を自動または無言で承認してはいけません。必ず、先にユーザーの確認を得てください。

承認が必要な実行を見つける

PR で承認待ちになっているワークフロー実行を確認します。

gh run list --commit <headSha> --json databaseId,workflowName,status,conclusion

または、リポジトリ全体の承認待ちの実行をすべて一覧表示します。

gh run list --json databaseId,workflowName,conclusion \
  --jq '.[] | select(.conclusion=="action_required")'

ブランチの最新コミットを確認し、実行が停止した原因を確かめます。

gh pr view <n> --json commits --jq '.commits[-1] | {author: .authors[0].login, message: .messageHeadline}'

確認と承認

計画（ステップ 3）では、「Awaiting workflow approval」という見出しの下に、承認待ちの PR を記載します。

• PR 番号と依存関係
• 停止中の実行を引き起こしたコミット（例：github-actions[bot] による chore: run biome:migrate のコミット）
• 承認待ちのワークフロー実行（例：CI）

承認する前に、ユーザーに明示的に確認してください。

「PR #54 では、github-actions[bot] によるコミット chore: run biome:migrate が原因で、CI ワークフローが承認待ちです。このワークフローの実行を承認してもよいですか？」

ユーザーが確認したら：

gh api -X POST /repos/:owner/:repo/actions/runs/<run-id>/approve

完了するまで実行を監視します。

gh run watch <run-id>

CI が正常に完了すれば、PR は合格チェックの条件を満たし、通常のワークフローに従ってマージできる状態になります。

5. 保留にしたメジャーアップデートを評価する

メジャーアップデートを保留するのが適切なデフォルトですが、「スキップ：メジャーアップデート」とだけ伝えても、ユーザーには判断材料がありません。結局、ユーザーが各 PR を開いて、あなたがすでに確認できる立場にあった情報を読むことになります。そのため、バージョンフィルターで保留になったすべての PR（各メジャーアップデートと、最もリスクの高い項目がメジャーアップデートであるグループ化された PR）について、そのアップグレードがこのプロジェクトにとってどの程度リスクがあるかを判断し、レポートに記載してください。この評価はユーザーに情報を提供するものであり、マージに進むことはありません。低リスクと判断したメジャーアップデートも、ユーザーが明示的に指定するまでは保留します。

これはマージの後に行ってください。ここでの作業によって、すでにマージ可能なアップデートが遅れてはいけません。プランが空でマージするものがない場合は、2行のプランだけで終わらせず、プランと評価をまとめて1つの返信で提示してください。その実行で役立つ成果は、評価の報告だけです。ユーザーから依頼があった場合に限り、評価を省略してください。

ここでも（ステップ 2 の）古さを確認してください。しばらく保留されていたメジャーアップデートこそ、グリーンのチェックが最も信用できず、報告でも最も重要になるため、チェックがどのベースに対して実行されたかを明記してください。ブランチが古い場合は、「ブランチの再構築」の作成者チェックに従って @dependabot recreate を投稿し、再構築されたブランチの CI を確認してから評価を書いてください。そうしないと、プロジェクトの現状に合わないテストスイートでアップグレードを評価することになります。

まず、Dependabot が PR に添付した情報を収集する同梱スクリプトを実行してください。

python3 <skill-dir>/scripts/dependabot_prs.py --notes 42 45        # --repo as usual

各 PR について、バージョン範囲、上流リポジトリ、PR が変更するファイル、PR のチェック状態、リリースノートと変更履歴のプレーンテキスト、およびそれらの中で破壊的変更、削除、新たな実行時の最低バージョンに言及している行を出力します。フラグが付いた行だけでなく、ノート全体を読んでください。フラグは読む際の補助であり、ブログ記事へのリンクしかないリリースでは何も表示されません。PR の本文にノートがまったくない場合、スクリプトはそのことを伝え、上流リポジトリの gh release を参照するよう示します。

次に、その情報がこのコードベースにとって何を意味するかを判断してください。通常、以下の質問を順に確認すると結論を出しやすくなります。

• PR の CI は成功しましたか？ Dependabot のブランチでは、新しいメジャーバージョンに対してプロジェクトのチェックが実行されています。そのため、グリーンであることは最も強い単独の根拠になります。ただし、CI が何をカバーしているか、実行からどれくらい経過しているかも記載してください。チェックがリンターだけのリポジトリでは、実行時の挙動については何も検証されていません。また、数か月前のグリーンは、その後変更された main に対して実行されたものです。レッドも同じように有益です。失敗したジョブのログには通常、具体的な問題が記されているため、「メジャーアップデート」を「X の変更が必要」に置き換えられます。ジョブのログは長いので、絞り込んでください。

  gh pr checks <n>                                    # names, states, run links
  gh run view --job <job-id> --log-failed | grep -iE -B3 'error|fail|cannot|not found' | head -60
  

• 依存関係の種類は何ですか？ 開発用ツール（リンター、テストランナー、バンドラー、型パッケージ）が壊すのはビルドであり、本番環境ではありません。また、型パッケージは独自の変更を含むのではなく、対応する実行時環境のメジャーバージョンに追従します。GitHub Actions のメジャーアップデートは、ほとんどの場合、実行時環境の更新か入力名の変更です。実際の対応が必要になるのは、フレームワークや、コードから直接呼び出すライブラリです。マニフェスト内のセクションと PR の変更ファイルを見れば、どれに該当するか分かります。ロックファイルだけを変更する PR は、プロジェクトが名前を指定してインポートしていない間接依存関係です。

• このプロジェクトは変更対象に触れていますか？ ノートから削除や名前変更を拾い出し、grep で検索してください。ライブラリならインポートと呼び出し箇所、Action なら uses: の行と入力項目、ツールなら設定ファイルを確認します。リポジトリ内で削除対象の機能を使っていなければ、そのメジャーアップデートは別の誰かにとってのメジャーアップデートです。

• 新しいバージョンの最低要件を満たしていますか？ 新たに必要となる Node、PHP、Python、またはフレームワークの最低バージョンが、見落とされやすい問題として最もよくあります。engines、require.php、python_requires、.nvmrc、runs.using、CI マトリックスなど、プロジェクトが宣言している要件と比較してください。

• アップデートの幅はどのくらいですか？ 2 つのメジャーバージョンを一度に上げる場合（5 → 7）、破壊的変更も 2 世代分あります。Dependabot が貼り付けたノートは通常、そのうち 1 世代分しかカバーしないため、どちらの変更を指しているか確認してください。 リポジトリがローカルにチェックアウトされていない場合は、gh search code --repo OWNER/REPO "<term>" と gh api repos/OWNER/REPO/contents/<path> を grep の代わりに使います。この制約によって確認できなかった点がある場合は、その旨を記載してください。

公開されていて読み取り専用の情報なら、根拠として何でも使えます。上流プロジェクトのリリースページや告知記事、依存関係やエンジンの制約を確認するための npm view ／ composer show ／ pip index、失敗したジョブのログなどです。実際にバージョンを上げて試す（新しいバージョンをインストールしてビルドとテストを実行する）ことが許されるのは、リポジトリの使い捨てコピー内に限り、ユーザーのチェックアウトでは決して行わないでください。また、読み取りだけでは疑問を解消できない場合に限ります。通常はやりすぎであり、判定が読み取りではなく試行実行に基づく場合は、レポートにその旨を記載してください。

レポートの「Held back」見出しの下に、評価をそれぞれ1つの箇条書きで記載します。PR 番号、依存関係、バージョン範囲、判定の順に記し、その後に短い段落を続けます。新しいメジャーバージョンで実際に何が壊れるのか、このプロジェクトがその影響を受けるかどうかと、その根拠（ファイル名または設定キーを明記）、PR をマージするには何が必要か（「merge #45」と言う、「先に設定を移行する」、「上流の X を待つ」など）を説明してください。通常は3～5文です。本当に複雑なケースでは長くてもかまいませんが、すべての文に根拠または判断を含め、変更履歴の要約にはしないでください。

一覧を見やすくするため、次の3つの判定のいずれかを使います。

• リスク低 — 破壊的変更はこのプロジェクトに影響せず、その根拠を示せる場合です。
• 先に対応が必要 — バージョンを上げる前に、このリポジトリでの変更が必要であり、その対象を具体的に示せる場合です。
• 判断できない — 変更内容の説明が不足しているか、使用方法が動的で grep では判断できない場合です。判断を確定するために必要な情報を記載してください。

実際にそうである場合は、迷わず「判断できない」としてください。誤った自信に基づく「リスク低」は、正直に不明点を伝えるよりもユーザーに大きな損害を与えます。レポートへの信頼を失わせるのは、まさにこれです。変更履歴を言い換えて評価を水増ししないでください。変更履歴は PR で確認できます。ユーザーが PR からは得られないのは、変更履歴と自身のコードとのつながりです。この手順の価値は、そこにあります。

6. 結果を報告する

計画と同じ、簡潔で事実に基づいたグループ別の箇条書きで締めくくります。

• Merged: PR 番号、依存関係、バージョン範囲を記載します。
• Needs another pass: コンフリクトが発生した PR、または古くなった PR を記載します。それぞれの状態を次の3つから明記してください。Dependabot が自動でリベースする（通常のケースで、必要なのは待つことだけ）、その PR に @dependabot recreate を投稿した、または再作成で他の人のコミットが失われるためユーザーの判断待ち。
• Awaiting approval: ワークフローの実行がメンテナーの承認待ちになっている PR を記載し、トリガーとなったコミットと必要な対応を説明します。
• Held back: メジャーバージョンの更新を、ステップ5の評価とともに記載します。セキュリティのラベルが付いたものは先頭に置き、セキュリティ更新であることを明記します。
• Skipped: その他の理由（チェック失敗、チェック未設定、バージョンを検証できない、保護ルールによりブロックなど）で保留した PR を記載し、ユーザーが対応を決められるよう理由ごとにまとめます。CI がない場合は、今後の進め方も明記してください。ユーザーが PR 番号を指定すればマージできます。
• Failed: エラーが発生したものを、エラー内容とともに記載します。

保留またはスキップしたセキュリティ更新には、必ず注意を促してください。Dependabot はそれらに security ラベルを付けます。メジャーバージョン更新でスキップされたセキュリティ修正は、後日再実行すればよいというものではなく、残項目の中で本当に注意が必要な唯一の項目です。そのため、評価を一覧の先頭に置きます。

変動する要素について

作成者フィルター。 Dependabot の PR は app/dependabot によって作成されます。スクリプトではこれがデフォルトです。リポジトリで従来の dependabot-preview やミラーボットを使用している場合は、--author を渡してください。

1.0 未満のバージョン。 0.5.6 → 0.6.0 はセマンティックバージョニングの規則上はマイナーバージョンの更新であり、Dependabot とこのスクリプトのどちらもそのように分類します。ただし、1.0 未満のプロジェクトでは、この範囲の更新で破壊的変更が含まれることがよくあります。スクリプトはこれらにフラグを付けます。報告時にはそのフラグも伝え、見落とさないようにしてください。

リリースノートは PR の本文から取得します。 Dependabot は上流のリリースノートと変更履歴を折りたたまれた <details> ブロックに貼り付けます。インベントリではこれらを無視します（他のプロジェクトの「Bumps X from A to B」という行が大量に含まれるためです）が、--notes はこれらを利用します。@types/* パッケージなど、リリースノートが存在しないエコシステムもあります。また、上流のプロジェクトがブログ投稿へのリンクしか掲載していない場合もあるため、ノート欄が空なのはよくあることであり、「変更なし」ではなく「上流を確認してください」という意味です。

グループ化された更新。 グループ化された PR（「Bump the npm-dependencies group with 5 updates」）は、含まれる更新のうち最もリスクの高いものに基づいて分類されるため、グループ内に 1 つでもメジャー更新があると、PR 全体が保留になります。PR は一体として扱われるため、リスクをその中で最も高いものとするのが適切です。

mergeStateStatus には repo トークンスコープが必要です。 これがない場合、スクリプトはこのフィールドを含めずに再試行し、その旨を通知します。ブランチ保護の状態を確認できないため、計画では予測できなかった保護ルール違反がマージ時に発生する可能性があります。

マージ可能性は遅延評価されます。 新しい PR では UNKNOWN が返される場合があります。スクリプトを再実行すると解決されます。

コミットのメタデータは、手書きの GraphQL クエリから取得します。 Dependabot のコミット末尾に付く情報（update-type: version-update:semver-minor）は、更新の種類が明記されている唯一の場所なので、スクリプトはコミットを読み取る必要があります。しかし、ほかのフィールドと一緒に commits を gh pr list に要求すると、GitHub はクエリ全体を拒否します。gh はこのフィールドを各 PR の各コミット 100 件に対する作成者 100 人分へと展開するため、該当する PR が実際にそれだけ存在するかどうかにかかわらず、--limit が約 48 を超えると 500,000 ノードの上限を超えます。

そのため、スクリプトは commits を含めずに PR を一覧表示し、その後、PR ごとにエイリアス付きの pullRequest(number:) を使ってコミットメッセージのみを取得する gh api graphql 呼び出しを 1 回実行します。100 件の PR を含むバッチ全体で測定したコストは、500 ノード（上限の 0.1%）とレート制限ポイント 1 でした。一覧取得のクエリに commits を再び追加しないでください。また、GraphQL クエリを拡張する場合は、ネストされたコネクションを含めないでください。最初に問題が発生したのは、コネクションを掛け合わせたためです。

PR のコミットを取得できない場合、その PR は本文にフォールバックします。バージョン情報は残っていますが、update-type の末尾情報はないため、unknown と判定されて保留になる可能性が高くなります。スクリプトは、その PR のノートにこの旨を記載します。読み取れない PR が 1 つあってもバッチ全体には影響しません。GitHub はエラーとともに残りのデータを返すため、スクリプトは取得できた情報をすべて保持します。