---

name: dependabot-alert-issue description: Dependabot alerts または外部 audit findings（例 pnpm audit の正規化 JSON）を確認し、解消 Issue を gh で作成するスキル。対象を「すぐ着手できるか」で分類し、着手可能なものは severity 毎、ブロック中のものは脆弱パッケージ＋解決バージョン毎にまとめる。既存 Issue/PR はスキップし、特定 alert の ignore/dismiss も設定できる。pnpm.overrides 等の品質が保証されない回避策は採らない。「Dependabot alerts から Issue」「pnpm audit の結果から Issue」「脆弱性対応の Issue」「dependabot-alert-issue」で必ず発動する。 argument-hint: "[--repo <owner>/<repo>] [--source <name> --input <findings.json>]" license: MIT

Dependabot Alert Issue

リポジトリの Dependabot alerts か外部 audit findings を確認し、脆弱性を解消するための GitHub Issue を gh で作る。起票した Issue への着手は姉妹スキル [[issue-start]] が担う。

脆弱性を 1 件ずつ Issue にするのではなく、まず「すぐ着手できるか」で分類し、そのうえで severity やパッケージの単位でまとめる。 すぐ着手できないものも止めずに、着手できるようになる条件を Issue に書き残す。後から読んだ人が、その条件を見て動けるようにするためである。

使い方

dependabot-alert-issue [--repo <owner>/<repo>] [--source <name> --input <findings.json>]

• --repo <owner>/<repo>: 対象のリポジトリ。省略すると現在の repo（gh repo view --json nameWithOwner -q .nameWithOwner）を対象にする。
• 入力ソースのデフォルト: --source と --input を渡さなければ、対象リポジトリの GitHub Dependabot alerts を読む。
• --source <name> --input <findings.json>: 渡したときだけ、外部 audit findings の JSON を入力にする（例: --source pnpm-audit --input findings.json）。 JSON は、後述の「外部 audit findings 入力」を満たす正規化済みの形にする。
• dismiss・ignore・リリース年齢のようなリポジトリ固有の設定は、引数ではなく設定ファイルに書く（「セットアップ」を参照）。
• Issue の下書きをユーザーに見せ、承認を得てから起票と dismiss を行う。意図とずれた起票や却下を避けるためである。

例: dependabot-alert-issue / dependabot-alert-issue --repo <owner>/<repo> / Dependabot alerts から対応 Issue を作って

• 自然文でも起動する（「Dependabot alerts から Issue」「pnpm audit の結果から Issue」「脆弱性対応の Issue」）。

前提

• ツール: gh（GitHub CLI。gh api を含む）、git
• 前提スキル: なし（起票後の着手は issue-start に引き継ぐが、必須ではない）
• MCP: なし
• シェル: bash（POSIX 互換のシェル）。コマンド例は bash を前提にしているので、Windows では WSL や Git Bash などの bash の環境で実行する
• Node.js は、設定ファイル（.config/skills/shoji9x9/dependabot-alert-issue.jsonc・common.jsonc など）を読むときだけ要る（同梱の scripts/skill-config/skill-config.mjs で読む）。 設定ファイルがどの層にも無ければ、Node.js なしで設定が無いものとして進める。設定ファイルがあって Node.js が無ければ、設定を読めないとして止まる。pnpm や python は要らない。

ブランチ運用・commit 規約の参照

Issue のタイトルの規約（conventional commits に似た接頭辞など）は、リポジトリごとに異なる。 解決の手順（設定ファイル、標準のドキュメントの探索、ユーザーへの確認の順）と、設定 common の conventions_doc の扱いは references/conventions.md にある。

セットアップ（特別処理・リリース年齢の設定）

「このパッケージは使っていないので dismiss する」「この alert は無視する」のようなリポジトリ固有の特別処理は、長い文になることがある。 そのため、スキルの引数ではなく .config/skills/shoji9x9/dependabot-alert-issue.jsonc に書く。スキルは起動するたびにこの設定を読む。 どのキーもリポジトリで揃える値なので、リポジトリの層だけに置ける（層と置き場所の決まりは references/config-files.md）。 次の例は、各キーと値の意味を示すものである。設定ファイル全体を書き直す雛形として使わない。 既にある設定ファイルに書くときは、例の後の「書くときは」で始まる箇条に書いた set と append でキーや要素を足す。全体を書き直すと、既にあるコメントや値が消える。

{
  // 解決バージョンが公開されてから着手するまでの最小の経過日数（任意）。
  // pnpm の pnpm.minimumReleaseAge などに当たる一般的な考え方。
  // 設定すると、解決バージョンの公開からの経過がこれより短い alert を「すぐ着手できない」に分類する。
  "minimum_release_age_days": 3,
  // 無視する alert（Issue を作らず、dismiss もしない）。条件を自由に書く。
  "ignore": ["テストでしか使わない <pkg> の low は見送る"],
  // dismiss する alert（Dismissal comment を付けて却下する）。理由は GitHub の dismissed_reason に合わせる。
  // 照合に使うキー（package / ecosystem / ghsa）は AND で評価し、書いたキーがすべて一致した alert だけを却下の対象にする。
  "dismiss": [
    // 特定の advisory 1 件だけが無関係なら、ghsa で絞る（もっとも狭い。推奨）
    {
      "ghsa": "GHSA-xxxx-xxxx-xxxx",
      "reason": "tolerable_risk", // fix_started | inaccurate | no_bandwidth | not_used | tolerable_risk
      "comment": "影響箇所を使っていないため許容する"
    },
    // パッケージそのものを使っていないなら、package で指定する（ecosystem でさらに絞れる）
    {
      "package": "<pkg>",
      "ecosystem": "npm", // 任意。別のエコシステムにある同名のパッケージを巻き込みたくないときに指定する
      "reason": "not_used",
      "comment": "このパッケージは本番の処理で使っていないため却下する"
    }
  ]
}

• 設定は、同梱の読み取りで取得する。exit 1（設定の誤りか、旧い場所の設定が残っている）なら、エラーの内容を利用者に示して止まる。

  node <このスキルのディレクトリ>/scripts/skill-config/skill-config.mjs dump dependabot-alert-issue
  

• 書くときは、読み取りの set と append を使い、既にあるキー・値・コメントを変えずに足す（作成と追記は非破壊）。既にあるキーは変えずに止まる（references/config-files.md「書き込みの決まり」）。 dismiss に 1 件足すなら、append dependabot-alert-issue dismiss '<要素の JSON>' --layer repo --unique-by ghsa のように、同じ advisory を重ねて足さない。

• 設定が無くても動く。そのときは ignore・dismiss・minimum_release_age_days が無いものとして、open な alert をすべて Issue にする対象にする。

基本フロー

1. 対象のリポジトリを確かめる（省略すると現在の repo）。--repo が現在の repo と違うときは、そのことを伝えてから対象を決める
2. 入力のモードを決める
   • GitHub alerts mode: open な Dependabot alerts を取得する（後述「gh メカニクス」。ページネーションを処理する）
   • 外部 audit findings mode: 指定された JSON ファイルを読み、後述「外部 audit findings 入力」に従って findings を確かめる
3. 設定の特別処理を当てる
   • ignore に当たる脆弱性は対象から外す（Issue も dismiss もしない）
   • GitHub alerts mode で dismiss に当たる alert は dismiss の候補として分け、Issue にする対象から外す（実行はユーザーの承認の後。後述）
   • 外部 audit findings mode には GitHub の alert 番号が無いので、dismiss はしない。 dismiss の設定に一致しても「dismiss できない」と報告し、Issue にする対象から外すかをユーザーに確認する
4. 既に解消の Issue・PR がある脆弱性は飛ばす。open な Issue と PR を検索し（後述）、同じパッケージ・GHSA・解決バージョンを扱うものがあれば対象から外す（Dependabot の更新 PR を含む）
5. 残った脆弱性を「すぐ着手できるか」で分類する（後述「着手可否の判定」）
6. まとめ方を決めて Issue を組み立てる（後述「グルーピング」）
7. タイトルと本文の下書きを作り、ユーザーに見せる
   • タイトルは規約の接頭辞に、severity を含める（例: fix(deps): [critical] bump <pkg> to <ver> to resolve advisories）
   • 本文は後述「Issue 本文の規約」に従う
   • タイトルと本文は、ユーザーに見せる前に writing-style スキルの手順で読み直す（スキルが無ければ省く）
   • dismiss の候補があれば、何をなぜ dismiss するかも一覧で見せる
   • 承認は references/user-confirmation.md の手順で求め、判断に要るもの（下書きの全文と dismiss の候補の一覧）を確認そのものに入れる。 確認のツールを使えないエージェントでも、それらを本文に出して返事を待つ
8. ユーザーの承認を得てから、Issue の起票（gh issue create --body-file）と dismiss（gh api）を実行する
9. 作った Issue の URL、dismiss した alert とその理由、飛ばした alert とその理由をまとめて報告する

着手可否の判定

脆弱性ごとに「すぐ着手できる」か「すぐ着手できない」かを分類する。すぐ着手できない場合は、妨げになっているもの（着手できるようになる条件）を記録する。

「すぐ着手できない」と判定するのは、主に次の場合である。

• 解決バージョンが公開されていない。GitHub alerts mode では first_patched_version が無く、外部 audit findings mode では patched_versions も patched も無い（修正版がまだ出ていない）
• リリース年齢が足りない。minimum_release_age_days が設定されていて、解決バージョンの公開からの経過がそれより短い。 公開日時はパッケージのレジストリで確かめる。取得できずに判断できないときは「すぐ着手できない」とし、その条件を明記する
• 依存のバージョンが固定されている。親の依存がバージョンを固定している transitive 依存などで、manifest を直接上げても解決できない
• transitive 依存が patched version に届くかを確かめていない。親の range が patched version を許していても、パッケージマネージャの実装によっては、通常の更新の操作で解決し直されないことがある（pnpm の詳細は references/pnpm-transitive-update.md）。 親の range が許していることだけを理由に、transitive 依存を「すぐ着手できる」に分類しない。 実際に patched version に届くことを確かめるか、確かめられないなら「lockfile の更新で関係のない依存のバージョンも上がりうる」ことを Issue に書いてから分類する

すぐ着手できない脆弱性については、妨げを解消する既存の Issue を調べる。 妨げになっているパッケージ（修正版を出す上流、またはバージョンを固定している親）に、それを取り除く Issue・PR が既にあることがある。 見つかれば、その Issue・PR の URL を着手できるようになる条件に書く（無ければ「見つからない」と書く）。

外部 audit findings mode では、finding の dependency_paths・direct_dependencies・why_summary を使って、direct 依存か transitive 依存かを見分ける。 補足の情報が足りないときは、入力元のスキルの調査結果を確かめるか、必要なコマンドを実行してから分類する。

すぐ着手できる例は次のとおりである。

• 脆弱なパッケージが direct 依存で、manifest を通常どおり更新すれば patched version に上げられる
• transitive 依存が、実際に更新の操作で patched version に届くことを確かめてある（親の range が許しているだけでは足りない）

すぐ着手できない例は次のとおりである。

• transitive 依存が、direct 依存の側で固定されている
• direct 依存を最新版にしても、patched version に上がらない
• transitive 依存が、親の range の上では許されているが、実際に patched version に届くかを確かめていない
• 解消には、既存の Issue の完了や上流のリリースを待つ必要がある

グルーピング

複数の脆弱性を 1 つの Issue にまとめる。まず着手できるかどうかで分け、それぞれ次の基準でまとめる。

すぐ着手できない脆弱性

• 脆弱なパッケージと解決バージョンの組ごとに、1 つの Issue にまとめる
• その中でもっとも高い severity をタイトルに使う
• 本文に、着手できるようになる条件（妨げと、それを解消する Issue の URL）を書く

すぐ着手できる脆弱性

• パッケージごとに更新先のバージョンを決める。そのパッケージの「すぐ着手できる」脆弱性をすべて解消するバージョンを選ぶ（基本は patched version のうち最新のもの）。 あわせて、そのパッケージのもっとも高い severity を記録する
• 記録した severity ごとに、1 つの Issue にまとめる（例: critical の Issue、high の Issue。1 つの Issue に同じ severity の複数のパッケージが入る）

Issue 本文の規約

• GitHub alerts mode では、alert を #N で書かない。#1 のように書くと、GitHub が Issue や PR へのリンクとして扱う。alert は必ず URL で参照する
• 外部 audit findings mode では alert の URL が無いことがあるので、GHSA の URL・advisory の URL・source を参照として書く。GitHub の alert が無いのに、alert の URL を作って書かない
• 書く情報は、対象のパッケージ、今のバージョンと更新先のバージョン、severity、該当する advisory（alert の URL か GHSA・advisory の URL）、影響範囲（runtime / development / unknown）である。 すぐ着手できない場合は、着手できるようになる条件（妨げと、それを解消する Issue の URL）も書く
• 品質が保証されない回避策は提案しない。pnpm.overrides のような上書きで解決を強制するのは保証の外で、しかもこのスキルは pnpm 以外のエコシステムでも使われる。 manifest の通常の更新で解決できないものは「すぐ着手できない」とし、着手できるようになる条件を書く（特定のパッケージマネージャに固有の回避策に頼らない）
• 実装の細部（具体的なコード片）を書きすぎない。実装はブランチの側（issue-start 以降）で扱う

dismiss の扱い

GitHub alerts mode で設定の dismiss に当たる alert は、ユーザーの承認の後に Dismissal comment を付けて却下する。外部 audit findings mode には GitHub の alert 番号が無いので、dismiss の API を呼ばない。

• 照合は、書いたキーの AND で行う。ルールに書いた照合用のキー（package / ecosystem / ghsa）がすべて一致した alert だけを却下の対象にする。書いていないキーは条件にしない
  • 特定の脆弱性 1 件を消したいときは、ghsa（advisory の ID）で指定する（もっとも狭い）。パッケージそのものを使っていないなら、package（必要なら ecosystem も）で指定する
  • package だけの広いルールでは、同じ名前のパッケージに後から出る別の alert（後日の critical など）も却下の対象になりうる。意図しない巻き込みを避けるため、できるだけ ghsa か、package と ecosystem の組まで絞る
• reason は GitHub の dismissed_reason（fix_started / inaccurate / no_bandwidth / not_used / tolerable_risk）に合わせる。comment を Dismissal comment として渡す
• dismiss も Issue の起票と同じく、下書きを見せ、承認を得てから実行する。承認なしに却下しない
  • 下書きを見せるときは、ルールごとに今いくつの alert が当たるかを挙げる。package だけの広いルールが想定外の alert を巻き込んでいないかを、ユーザーが確かめられるようにする

外部 audit findings 入力

Dependabot alerts が作られない状況（例: pnpm 11 以降の複数ドキュメントの lockfile に Dependabot が対応していない）では、外部 audit findings を入力にして Issue を作る。 このモードでも、グルーピング・着手可否の判定・既存の Issue と PR を飛ばす処理は、GitHub alerts mode と同じ考え方で行う。

入力の JSON は次の形にする。

{
  "source": "pnpm-audit",
  "generated_at": "2026-06-11T00:00:00.000Z",
  "findings": [
    {
      "package": "example",
      "ecosystem": "npm",
      "severity": "high",
      "ghsa": "GHSA-xxxx-xxxx-xxxx",
      "advisory_url": "https://github.com/advisories/GHSA-xxxx-xxxx-xxxx",
      "title": "Advisory title",
      "vulnerable_versions": "<1.2.3",
      "patched_versions": ">=1.2.3",
      "patched": "1.2.3",
      "current_versions": ["1.0.0"],
      "dependency_paths": ["project>example"],
      "direct_dependencies": ["parent-package"],
      "why_summary": "parent-package > example",
      "context_note": "Dependabot support for pnpm 11+ multi-document lockfiles is pending",
      "manifest": "pnpm-lock.yaml",
      "scope": "unknown"
    }
  ]
}

• 必須のフィールドは source・findings[]・package・severity である
• ghsa か advisory_url のどちらか、patched_versions か patched のどちらかを、できるだけ入れる
• scope は runtime / development / unknown のどれかにする。判定できなければ unknown にする
• patched_versions が範囲の表現で、1 つの具体的なバージョンに変えられない場合は、patched を空にしてよい。そのときは「解決バージョンの確認が要る」か「すぐ着手できない」に分類する
• 同じ package と ghsa の組の finding が複数あればまとめ、current_versions と dependency_paths の重複を除いて本文に書く
• direct_dependencies・why_summary・context_note は任意である。入力元のスキルが、依存のつながりや背景の情報を足せる場合に使う

外部 audit findings mode の Issue 本文には、次のものを必ず書く。

• source（例: pnpm audit）と、作成した日時
• GHSA・advisory の URL（無ければ advisory の title と package）
• 脆弱な範囲、patched の範囲、今検出されている version
• dependency path・direct dependency・why summary（ある場合）
• GitHub の Dependabot alert が無い理由が分かっていれば、その補足（例: Dependabot が pnpm 11 以降の lockfile に対応していない）

gh メカニクス

open な alert の取得（全件。ページネーションを処理する）

gh api --paginate \
  "/repos/<owner>/<repo>/dependabot/alerts?state=open&per_page=100" \
  --jq '.[] | {number, url: .html_url, severity: .security_advisory.severity,
    ghsa: .security_advisory.ghsa_id, pkg: .security_vulnerability.package.name,
    ecosystem: .security_vulnerability.package.ecosystem,
    scope: .dependency.scope, manifest: .dependency.manifest_path,
    patched: .security_vulnerability.first_patched_version.identifier}'

• per_page=100 と --paginate で、すべてのページを取得する。デフォルトの 30 件で打ち切らず、必要な範囲をすべてページネーションで取得する。
• dependency.scope は runtime か development である。first_patched_version が null なら、修正版は公開されていない。
• 取得が 403 や 404 で失敗したときは、Issue を作らずに原因を切り分け、ユーザーに見せて止まる。
  • 403 の場合は、Dependabot alerts が無効か、token に要る権限が無い。 リポジトリの設定（Settings → Code security）で Dependabot alerts を有効にするか、security_events スコープを持つ token で認証し直す（例: