my-review-dependabot-pr
Dependabot PR をレビューし、tmp/docs/pr-review-{PR番号}.md にまとめる
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Dependabot PR をレビューし、tmp/docs/pr-review-{PR番号}.md にまとめる
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | my-review-dependabot-pr |
| description | Dependabot PR をレビューし、tmp/docs/pr-review-{PR番号}.md にまとめる |
| disable-model-invocation | true |
| argument-hint | ["GitHub PR URL or PR番号"] |
ghro CLI で $0(GitHub PR URL または PR 番号)をレビューして、tmp/docs/pr-review-{PR番号}.md にまとめて。
$0 が指定されていない場合は、ユーザーに GitHub PR URL または PR 番号を確認すること。
リポジトリ特定:
owner/repo をパースし、ghro に --repo owner/repo で渡すowner/repo を判定する。判定できなければユーザーに確認するPR タイトル解析:
bump <パッケージ名> from <旧バージョン> to <新バージョン> の形式が多い情報源の優先順位(上から順に確実性が高い):
ただしセキュリティ面(CVE/GHSA・深刻度・影響範囲・修正導入版)に限れば、紐づく Dependabot alert(後述)が最も確実な一次情報で、Release notes より優先する。
ghro コマンド例:
ghro pr view <PR番号> --repo owner/repo --json number,title,body,headRefName,labels,additions,deletions,filesghro pr diff <PR番号> --repo owner/repogh pr checks <PR番号> --repo owner/repoghro api 'repos/<owner>/<repo>/dependabot/alerts?state=open&per_page=100' --paginate --jq '.[] | {number, package: .dependency.package.name, manifest: .dependency.manifest_path, ghsa: .security_advisory.ghsa_id, cve: .security_advisory.cve_id, severity: .security_advisory.severity, range: .security_vulnerability.vulnerable_version_range, first_patched: .security_vulnerability.first_patched_version.identifier}'(デフォルトは全 state・1 ページ 30 件で照合漏れするので、open に絞ってページングする)Dependabot body の読み方:
Dependabot は body に決まったセクションを埋め込むので、該当箇所だけ拾う:
Release notes — 各バージョンのリリースノート。Breaking Changes / セキュリティ修正の主な情報源Commits — 期間内のコミット一覧。リリースノートに載らない小さな破壊的変更が出ることがある不明な点は推測せず「未確認」と記載する。
レジストリ tarball と git タグの中身は一致しないことがあるため、これだけで混入を断定はできない。あくまで「不審な変更の手がかり」を得るための補助。Dependabot PR body の "Updates ..." リンクやパッケージメタ情報から上流リポジトリを特定し、compare を確認する:
https://github.com/<owner>/<repo>/compare/<旧タグ>...<新タグ>ghro api repos/<owner>/<repo>/compare/<旧タグ>...<新タグ>(commits / files / 差分行数を JSON で取得)着目点:
postinstall / preinstall / bin / scripts フィールドの追加・変更git diff では検出できないものがあるので過信しないこと:
Dependabot PR にはバージョンアップ起因とセキュリティ修正起因があり、後者だけがリポジトリの Dependabot alert に紐づく。PR 単体ではどちらか判別しづらく、PR と alert の紐づけは API でも直接は取れないため、alert 一覧との照合で判定する。セキュリティ起因かどうかに関わらず Dependabot PR では毎回実施する:
package-lock.json)range に現行バージョンが含まれ、first_patched を PR の新バージョンが満たす(=この PR で解消される)state=open で保証済み一致した alert の詳細を引けば、Release notes に載らないこともある CVE/GHSA・深刻度・影響範囲・修正導入版を確実に取得でき、これがセキュリティ判定の一次情報になる:
ghro api repos/<owner>/<repo>/dependabot/alerts/<番号> --jq '{number, state, ghsa: .security_advisory.ghsa_id, cve: .security_advisory.cve_id, severity: .security_advisory.severity, summary: .security_advisory.summary, range: .security_vulnerability.vulnerable_version_range, first_patched: .security_vulnerability.first_patched_version.identifier, url: .html_url}'1 つの PR が複数の脆弱性を一度にまとめて修正することもあるので、複数の alert が一致しないか意識する。
各項目は diff・PR body・Release notes・Dependabot alert を調べ、判断と根拠をあわせて記載する。テンプレートの各フィールドがそのまま調査すべき観点になる。上流 release 差分(補助)で不審点があれば「未確認事項」または「結論」で触れる。
tmp/docs/pr-review-{PR番号}.md に以下の構成で出力する:
# PR #{PR番号}: {PRタイトル}
## 概要
- パッケージ: {パッケージ名} {旧バージョン} → {新バージョン}
- 依存の種類: {ランタイム依存 / 開発依存}
- バージョン変更: {メジャー / マイナー / パッチ}
## 主要な確認結果
- Breaking Changes: {有無と詳細}
- セキュリティ: {紐づく Dependabot alert と CVE / GHSA・深刻度・影響範囲・修正導入版。この PR で解消されるか。なければ「なし」}
- サポートバージョン: {言語・ランタイムの最低バージョン変更の有無}
- CI 状況: {pass / fail / pending と失敗の概要}
- 連鎖更新: {更新対象以外の意図しない依存変更の有無}
## 影響範囲
{manifest / lockfile / diff から見えるアプリケーションコードへの影響}
## 未確認事項
{情報不足や追加確認が必要な点。なければこのセクション自体削除すること}
## 結論
{問題なし / 要確認 / マージ非推奨}
{判断の根拠を簡潔に}
#123 は Issue/PR へ自動リンクされてしまうので、そのまま書かない[alert #123](https://github.com/<owner>/<repo>/security/dependabot/123) のように対象 URL への Markdown リンクにする。セキュリティ欄・結論など、言及するたびに毎回リンクにするgit の変更内容から Semantic Commit Messages 形式のコミットメッセージを提案する。`git commit` を実行する前に必ず経由すること。ユーザーが「コミットして」「コミットメッセージを考えて」と求めた時も、issue 対応や PR 作成の一環で Claude 自身がコミットしようとする時も対象。ステージ済み・未ステージ・新規追加(untracked)すべての変更を読み、Why を重視した文面を提案し、承認を待つ。
ghro CLI で Issue を調査し、tmp/docs/plan-for-issue-{Issue番号}.md に作業計画を作成する
論点整理と反証のために Codex CLI と議論する。複数案のトレードオフを比較したい、自案への反証や弱点を検証したい、判断基準を確認したいときに使う。実装やファイル変更は一切行わず、議論と最終報告のみ