菜单
ライブラリ更新pull requestのレビュー。 dependabotやrenovatebotが作成したPR、または手動で作成されたライブラリ更新PRをレビューし、 release note分析、コード更新、依存関係調査、過去の失敗調査を行う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
リポジトリのセキュリティ調査を領域ごとに進める。 調査対象リストと観点リストに基づき、未調査の領域を選んで調査し、レポートを出力する。 複数sessionにまたがる長期作業を想定し、現状を確認して続きの作業を行う。
PRのレビュー報告書を作成する。bugや脆弱性の調査だけでなく、exportされた対話コンテキスト・PR概要欄・実装されたコードの整合性を確認し、実装者の正気を疑う。 ユーザーが「PRのレビュー報告書を書いて」「対話コンテキストと共にコードレビューして」「このPRの正気を疑って」と言った時に使用する。
対話コンテキストをexportする。 会話で共有された目的・意図・設計判断・制約条件を `.dev/contexts/` ディレクトリに書き出し、PRが存在する場合はPRコメントにも投稿する。次の作業者（レビュワー、別セッションのAI、バグハンティングのAIなど）に引き継ぐ。 ユーザーが「コンテキストを書き出して」「対話コンテキストをexport」「会話した内容を.devに保存して」と言った時に使用する。
対話コンテキストをimportする。 `.dev/contexts/` ディレクトリに保存された過去の対話コンテキストを読み込み、開発の継続やレビューに活用する。 ユーザーが「コンテキストを読み込んで」「対話コンテキストをimport」「.devのコンテキストを読んで」と言った時に使用する。
定石外発想で実装をシンプルにする。現状の発展型ではなく、実装の裏にある暗黙の前提条件を1つずつ外し、よりシンプルな別解がないか検討する。 ユーザーが「定石外発想で」「前提を疑って」「もっとシンプルにできないか」と言った時に使用する。
Codex CLIと相談するスキル。 ユーザーが「codexと相談して」「codexに聞いて」「codexにレビューしてもらって」と言った時に使用する。 現在の会話コンテキストに基づいてCodex CLIにプロンプトを送り、結果を要約して報告する。
| name | library-update-review |
| description | ライブラリ更新pull requestのレビュー。 dependabotやrenovatebotが作成したPR、または手動で作成されたライブラリ更新PRをレビューし、 release note分析、コード更新、依存関係調査、過去の失敗調査を行う。 |
| argument-hint | [PR-URL-or-number] |
ライブラリを更新する変更をレビューし、必要に応じてバージョン間のmigrationや、breaking changeへの対応も行う為の手順を説明します。 コマンドやファイルの具体例としてNode.jsを使って説明していますが、実際に変更されたライブラリやプログラム言語の常識に照らし合わせて適宜読み替えてください。
以下に示した形式に従って章立てし、レポートを作成してください。 外部のドキュメントを参照した場合はそのURLを明記してください。
ライブラリの概要を調査してください。 ライブラリ内READMEや公式サイトのドキュメントを確認して、何を実現するために、どのような用途で使われるライブラリなのかを報告してください。
package.jsonを読んで、このpull requestによって変更される前と後のバージョン情報と、それぞれのリリース日時を報告してください。
npmjs.comやgithubを調査し、major versionの更新の有無を報告してください。 このpull requestではpatch versionやminor versionを更新しているが、実はそれが最新版ではなく、major versionの更新があるかもしれません。 major version更新ではライブラリの名前が変更されたり、リポジトリがorganizationに移管されたりする事があります。
このpull requestで何が変更されたか、その範囲を把握してください。
lock file差分から、更新・追加・削除されたパッケージを列挙してください。
例: npmの package-lock.json の場合、gh pr diff や git diff でlock file差分を取得する。個別パッケージの周辺コンテキストは grep -C15 '<パッケージ名>' package-lock.json で確認できる。
ライブラリの依存関係を確認してください。
package-lock.jsonを読んで依存関係を確認してください。grep -C15 ライブラリ名 package-lock.json のようなコマンドが有効です。
リポジトリ内で、そのライブラリや実行環境が参照・指定されている箇所を調査してください。
import文やrequire文だけでなく、設定ファイル・Dockerfile・CI設定・開発環境設定など、バージョンが指定されている箇所も調査対象に含めてください。
git grep ライブラリ名 に加えて、バージョン番号やパッケージ名での検索も行ってください。
調査結果は、参照箇所をファイル単位で一覧にまとめてください。このリストはセクション7-2「バージョン整合性の確認」の入力として使います。 セクション3・4等の他セクションで読んだファイルにもバージョン指定が含まれている場合があるので、漏らさずリストに含めてください。
変更内容を要約してください。 ライブラリの公式サイトやGithubを参照し、release noteやchangelog、migration guideを詳しく読んで変更内容を把握してください。 機能追加やAPIの仕様変更のうち、特にアプリケーション側で使っている機能に関係がありそうな変更を抜き出して、報告してください。 変更前と後の間に含まれる、全バージョンの変更内容を1つずつ確認する必要があります。
重要：pull requestの概要欄に書かれている説明は誤っている可能性があるので、無視してください。現状のコードとdiffだけを参考にしてください。
ライブラリや実行環境の更新に伴い、アプリケーションコード・設定ファイルの修正が必要か確認してください。 必要に応じてpull requestの作成を提案してください。
以下の2つの観点を区別して確認してください。
ライブラリのAPIが変化した場合は、アプリケーションのコードを変更する必要があります。
release noteやchangelogだけで正しい変更方法がわからない場合は、githubのcommits内の実際の変更差分や、公式ドキュメントも確認してください。 その変更内容も報告してください。
PRで変更されたバージョン番号が、リポジトリ内の他の箇所でも参照されていないか確認してください。
以下の手順で調査してください：
注意：
22.x等）やエイリアスで管理されている場合がある興味深い更新があれば、報告してください。 例えば以下のような内容です：
このリポジトリにおいて、今回更新しようとしているライブラリに関する問題が発生した事がないか、調査してください。 pull requestとissueをライブラリ名で検索し、以下の例に当てはまるような事例があれば報告してください。
問題が見つかった場合は、それが解決されているか確認してください。
レポート全体を横断的に見直し、セクション間で矛盾や漏れがないか確認してください。
齟齬が見つかった場合は、該当セクションを修正してください。
レポートの形式を見直してください。出力先がGithubのコメント欄の場合は、それに適した形式で出力してください。
#12345 ではなく https://github.com/:owner/:repo/issues/12345 と書く。 URLが左右の文字とくっつかないように、半角スペースを適宜付ける。こうすればクリッカブルなリンクとしてwebブラウザ上に描画される。
出力先がGithubのpull requestの場合は、レポート提出後に適切なラベルを付けてください。 例えばCVE番号が発行されているような重要なセキュリティアップデートのpull requestには、「security」ラベルを付けてください。
あなたがGitHub Actions上で実行されているClaude Codeの場合、タスクを遂行するための権限が十分与えられていないかもしれません。 リポジトリの管理者が適切に対応するために、必要な権限を報告してください。