dependabot

Topics in the source

• Dependabot Update Triage Workflow
• なぜ全 PR でリスク分析を必須にするか
• 前提条件
• ホスト repo に依存する慣習について
• 手順
• 1. Dependabot PR の収集
• 2. 各 PR のメタデータ抽出
• 3. リスク分析（必須・全 PR 対象）

Dependabot が開いた依存更新 PR を一括で取り込み、各更新を upstream リポジトリまで遡って リスク分析し、マージ可否の判断材料を Design Doc としてユーザーに返す。ユーザーが採否を 決定したら、承認分を反映し、判断結果と根拠を ADR に記録する。 サプライチェーン攻撃（メンテナアカウントの乗っ取り、悪意ある postinstall スクリプトの 混入、リポジトリ移管後の改ざん、typosquatting な transitive 依存の追加）が増えており、 semver の bump 種別（patch / minor / major）や互換性スコアだけでは安全性を判断できない。 patch であっても公開物に悪意あるコードが含まれうる。 このため本 skill は bump 種別を問わずすべての PR を upstream まで遡って確認し、 リスク分析を省略しない。「patch だから自動マージ」という分岐は設けない。 gh auth status で GitHub 認証済みであること ホスト repo が Dependabot（.github/dependabot.yml）を有効化していること リスク分析のために upstream リポジトリやパッケージレジストリへ WebFetch / gh api でアクセスできること 本 skill には以下の任意（optional）ステップが含まれる。ホスト repo がその慣習を採用して いない場合は該当ステップをスキップする。 Design Doc: docs/design/ を採用する repo のみ、トリアージ結果を Design Doc として 残す（ステップ 4）。不採用の repo では結果を会話および各 PR へのコメントで返す。 ADR: docs/adr/ を採用する repo のみ、判断結果を ADR に記録する（ステップ 7）。 不採用の repo ではスキップし、結果を ADR PR のコメント等で残すに留める。 ADR / Design Doc のファイル名規約・言語は host repo の規約（.claude/rules/ 等）に従う。 開いている Dependabot PR を一括で取得する（バッチ処理 — 全件を対象にする）。 0 件なら「対応すべき Dependabot PR はありません」と伝えて終了する。 Dependabot のグループ更新 PR（複数依存をまとめた PR）も 1 件として扱う。 セキュリティ更新 PR（security ラベル付き）は優先度を高く扱う。そのパッケージが override 機構（pnpm overrides / npm overrides / yarn resolutions）にも載っている 場合は、se

This is an excerpt. Refer to the complete source and its current requirements.