review-dependabot

Dependabot PR のレビュー

FMC の geo React アプリ向けワークフローです。Dependabot の設定（グループ、スケジュール、無視する項目、dependabot.yml の変更）は、skill tech-stack → references/dependabot.md にあります。このスキルでは、レビューとマージの判断を扱います。

リポジトリの対象範囲

現在のワークスペースの Git リポジトリのみで作業してください。他のリポジトリの Dependabot PR はレビューもマージもしないでください。--repo を指定せずに、プロジェクトのルートから gh を実行してください。ワークスペースが Git リポジトリでない場合、または .github/dependabot.yml がない場合は中止してください。

FMC の一般的なアプリリポジトリでは、対象ブランチは develop です。Dependabot PR を main にマージしないでください。各 PR の baseRefName を確認し、誤っているように見える場合は AskUserQuestion を使用してください。

ポリシー：エコシステムごとに未解決の Dependabot PR は 1 件までです。次の PR が作成される前に、マージするか、明示的に保留（クローズして無視）してください。

レビューワークフロー

1. コンテキストを確認する

gh pr list --author app/dependabot --state open --json number,title,baseRefName,headRefName,labels

未解決の各 PR について：

gh pr view <number> --json title,body,baseRefName,headRefName,mergeable,statusCheckRollup,author,labels
gh pr diff <number> --name-only

PR の本文が変更履歴です。 トリアージには gh pr view の body を使用してください。判断が必要なパッケージについて、本文が空、または明らかに不完全でない限り、GitHub のリリース、npm のページ、その他の外部の変更履歴は取得しないでください。

グループ化された PR では、パッケージごとにセクションが分かれています。すべて確認してください。リスクのある項目が 1 つでもあれば、グループ全体を保留できます。差分を読んだり、コードベースを検索したりする前に、本文の破壊的変更、移行、非推奨化の見出しを確認してください。

タイトルに含まれるグループ名も記録してください（例：app-framework-minor-patch）。

未解決のセキュリティアラートも一覧表示してください。PR リストが空でも、未解決のアラートがないとは限りません。

gh api repos/{owner}/{repo}/dependabot/alerts \
  --jq '.[] | select(.state=="open") | "\(.dependency.package.name) \(.security_advisory.severity) \(.dependency.manifest_path) fixed in \(.security_vulnerability.first_patched_version.identifier)"'

2. リスクを分類する

Tier	例	アクション
低	パッチ版の開発ツール（knip、husky）、型定義、独立したユーティリティ	CI が成功 → マージ
中	グループ化されたフレームワーク依存関係のマイナー版／パッチ版、vite、oxlint／oxfmt、Playwright	PR 本文のリリースノートを読む。利用箇所を抜き取り確認する。ノートに動作変更が記載されている場合は、ローカルで bun run build と bun oxlint を実行する
高	react、@tanstack/*、maplibre-gl、react-map-gl、prisma、better-auth、zod、tailwindcss、typescript のメジャー版	PR 本文のノートと移行セクションをすべて読む。影響を受ける API をコードベースで検索する。ビルド、lint、単体テストを実行し、マップ／認証／ルーティングに影響する場合は Playwright も実行する。すべて成功したらマージする
重要な判断	Semver のメジャー版、明示的な破壊的変更、peer dependency の競合、CI の失敗、または変更履歴が不明瞭な場合	AskUserQuestion を使用してください。人間が判断するまでマージしないでください（確認を求めるのはこの Tier のみです）

セキュリティ更新は、最低でも中として扱ってください。ノートを確認し、セキュリティラベルが付いていても内容を確認せずにマージしないでください。これらはクールダウン期間を回避し、非常に新しいリリースを提案する場合があります。

3. コードで調査する

PR 本文のリリースノートまたはリスク区分に「調査」とある場合：

1. gh pr diff <number> — ロックファイルの差分だけでなく、package.json を重点的に確認します。
2. 破壊的変更のセクションに記載された API（非推奨の props、名前が変更されたエクスポート、設定キーなど）をローカルのチェックアウトで grep します。
3. 更新が該当領域に関わる場合は、関連する FMC スキルを読み込みます（react-dev、react-map-gl、tanstack-router-conventions、tanstack-start-conventions、playwright-skill など）。
4. CI ログで peer dependency の警告を確認します。

browserslist の更新：Dependabot は browserslist クエリを変更しませんが、ロックファイルで caniuse-lite が更新される場合があります。マージ後、bun oxlint と bun run build が引き続き成功することを確認します（スキル tech-stack → references/browser-target.md）。

GitHub Actions の更新：minor/patch のグループ化を優先します。アクションのリリースノートで runner/input の名前変更を確認し、ワークフローが組織のシークレットと permissions に引き続き対応していることを確認します。

Docker の更新：ベースイメージは毎月更新します。OS やパッケージの変更を確認し、アプリがコンテナーを配布する場合はローカルで再ビルドします。

4. PR がないセキュリティアラート（Bun）

Bun のリポジトリでは、Dependabot はセキュリティ更新用の PR を作成できません。GitHub はアラートを npm エコシステムとして記録するため、セキュリティジョブは npm_and_yarn として実行され、package-ecosystem: bun のエントリーを無視して bun.lock で中断します。デフォルトブランチでは、アラートが開いている間、プッシュのたびに npm_and_yarn in /<dir> for <packages> - Update #… という名前の失敗した実行が表示されます。

これは dependabot.yml やワークフローでは修正できません。修正しようとしないでください。失敗した実行を、手動で更新する合図として扱います。

1. 上記のアラート一覧から、パッケージ、ディレクトリ、修正済みバージョンを確認します。
2. 直接依存の場合は、package.json に修正済みバージョンを設定し、そのディレクトリで bun install を実行します。推移的依存の場合（bun why <package>）は、親パッケージを更新するか、overrides エントリーを追加する前に AskUserQuestion を使用します。
3. ほかのセキュリティ更新と同様、リスク区分は最低でも medium です。PR 本文がないため、アドバイザリ（gh api repos/{owner}/{repo}/dependabot/alerts/<number>）を読みます。
4. プロジェクトのチェックを実行し、スキル finish-work を使って Dev: Bump <package> to <version> としてコミットします。コミット本文にはセキュリティ修正であることを記載し、リポジトリの通常の変更取り込み手順に従ってプッシュします。
5. アラート一覧が空であること、次のプッシュで npm_and_yarn の実行が失敗しないことを確認します。

5. AskUserQuestion を使用するタイミング

エージェントだけでは安全に判断できない場合は、AskUserQuestion を使用します。

• 本番環境またはフレームワークの依存関係で Semver の major 更新がある
• 破壊的変更が、セッション中に完全には検証できないコードパスに影響する
• CI が失敗し、修正方法が明確でない、または更新の範囲を超えてしまう
• グループ化された PR に安全なパッケージとリスクのあるパッケージが混在している — すべてマージするか、分割するか、クローズしてグループを再設定するか
• 判断が必要なパッケージについて、PR 本文のリリースノートが欠落しているか、内容が矛盾している
• 更新を今すぐ適用するか、ignore ルールを提案するか
• マージするか、関連する PR や上流の修正を待つか
• 既知のリリースについて、まだバージョン更新 PR がない — クールダウン期間中か、次回の定期チェック待ちの可能性がある

具体的な選択肢を提示します。たとえば、ローカルビルド後にマージする、クローズして ignore を追加する、または来週まで延期する、といった選択肢です。

6. マージ

要件：

• 必須チェックがすべて成功している（キューの滞留を解消するために、赤い状態のままマージしてはいけません）
• 上記の表に従ってリスク区分に対応している
• マージを妨げる未解決のレビューコメントがない

履歴を直線的に保つため、rebase merge を使用します。

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

リポジトリで CLI による rebase が許可されていない場合は、GitHub UI で Rebase and merge を使用します。

Dependabot の PR はsquash しないでください。bisect を容易にするため、依存関係の更新ごとに 1 つのコミットを保持します。

develop へのマージ後は、ベースブランチの CI が失敗しない限り、追加の対応は不要です（失敗した場合は、ホットフィックスの後続対応として扱います）。

7. マージせずに保留する

次の場合は、マージせずにクローズします。

• メジャーアップデートで、専用の移行期間が必要な場合
• グループが大きすぎて、一度にレビューできない場合
• 既知のアップストリームのリグレッションがある場合（PR のコメントにイシューへのリンクを記載）

PR を開いたままにするよりも、.github/dependabot.yml に対象を絞った ignore を追加することを優先します（理由は PR のコメントに記載してください）。open-pull-requests-limit: 1 によってキューがブロックされることを忘れないでください。

やってはいけないこと

• 定期的な Dependabot のマージと同じセッションで、アプリのコードをリファクタリングしないでください。ただし、アップデートに必須の場合は除きます。
• 問題のあるアップデートを通すために、CI ワークフローを変更しないでください。代わりに問題として報告してください。
• セキュリティアラートが未解決の状態で「Dependabot の作業はすべて完了した」と報告しないでください。また、失敗した npm_and_yarn のセキュリティ実行を黙らせようとしないでください。
• それぞれをレビューせずに、複数の未オープンの Dependabot PR をまとめてマージしないでください。