security-alertlisted

# Dependabot Security Alert Triage Workflow Dependabot の security alert（GitHub Advisory に基づく脆弱性アラート）を一括でトリアージし、 direct / transitive を判別して適切な修正方法で解決する。トラッキング Issue を作成し、修正 PR を 出し、判断結果と根拠を ADR に記録する。 ## なぜ security alert を update PR と別 skill で扱うのか `dependabot` skill は Dependabot が開いた **依存更新 PR** を捌く。security alert は別物として扱う。 - security alert は `gh api repos/{owner}/{repo}/dependabot/alerts` から取得する。open PR 一覧 には現れない。 - **alert に対応する PR が存在しないことがある**。脆弱なパッケージが transitive 依存の場合、 bump すべき直接の宣言行が `package.json` に無いため、Dependabot は security update PR を 合成できず、alert だけが残る。 - **alert の `state` は安全性の証明ではない**。GitHub の auto-triage は通知量を減らすために alert を `auto_dismissed` にするが、脆弱版は lock に残ったままである（ステップ 1）。 - transitive 依存の解決には、bot PR のマージではなく package manager の **override 機構** （pnpm `overrides` / npm `overrides` / yarn `resolutions`）を使うことが多い。 このため、`dependabot` skill の「open PR を列挙してトリアージ」とは収集元も解決手段も異なる。 本 skill は特に **transitive 依存で PR が起票されないケース**を主対象にする。 ## 前提条件 - `gh auth status` で GitHub 認証済みであること - ホスト repo が Dependabot security alert を有効化していること（リポジトリ設定の "Dependabot alerts"） - alert / advisory の取得のため `gh api` および WebFetch でアクセスできること - alert を読むには `gh` のトークンに security_events スコープ（または対象 repo の admin / security 権限）が必要 ## ホスト repo に依存する慣習について 本 skill には以下の任意（optional）ステップが含まれる。ホスト repo がその慣習を採用して いない場合は該当ステップをスキップする。 - **status ラベル**: `status: *` ラベル運用がある repo のみ、トラッキング Issue のラベルを 更新する。 - **ADR**: `docs/adr/` を採用する repo のみ、判断結果を ADR に記録する（ステップ 8）。 不採用の repo ではスキップし、結果を