📦
ライブラリ更新内容確認をスキル化する
作ったもの
私が参加しているプロジェクトでは週末になると、renovateがライブラリ更新PRを作成するようになっています。
開発者は月曜日にPRを確認して、更新内容を把握した上で、更新するかどうかの判断をする必要があります。
更新内容の確認＋影響箇所の確認について、リリースノートのURLを渡すことで、claudeにやってもらうコマンドを作成していたのですが、PRの数だけコマンドを実行するのは面倒だなと思っていました。
そこで、ライブラリ更新内容確認の作業を一括でやらせるスキルを作成しました。
得られたもの
このスキルを作成したことで以下の課題を解決しました
- ライブラリ更新内容確認作業がコマンド一発でできるようになった
- コマンドを実行するためにリリースノートのURLを毎回コピーする必要がなくなった
スキル構成
check-update-all-dependencies/
├── SKILL.md
└── references/
└── dependencies-release-notes.json
キモはreferences/dependencies-release-notes.jsonで、ここに依存ライブラリ名をキー、リリースノートのURLを値とするJSONを置いています。
これにより、リリースノートを特定するためにclaudeが頑張る必要がなくなって、安定して更新内容の確認ができるようになります。
[
{"name": "kotlin", "releaseNoteUrls": ["https://github.com/JetBrains/kotlin/releases", "https://kotlinlang.org/docs/releases.html"]},
...
]
スキル本体は結構単純なものです。
---
name: check-update-all-dependencies
description: Renovate が作成した依存関係更新PRをレビューし、変更内容・影響分析レポートをPRにコメントとして自動投稿する。dependenciesラベルの付いた複数のPRを一括でレビューしたいとき、または依存関係更新の影響を分析したいときに使用する。
allowed-tools: Bash(gh pr *), Bash(gh api *), Read(*/package.json), WebFetch, Grep, Glob, Task
---
# Tasks
## 1. PR検索・選択
- `gh pr list --repo org/repo --label dependencies --state open --json number,title,url` でPR一覧取得
- 取得したPRの数だけ Task ツール（subagent_type: general-purpose）を並列起動し、以降の作業を各タスクで実行する
## 2. PR情報取得・解析
- `gh pr view --repo org/repo {number} --json title,body,number,url` で情報取得
- PR本文からパッケージテーブルを解析:
- パッケージ名（例: `io.github.takahirom.roborazzi`）
- バージョン変更（例: `1.52.0` → `1.54.0`）
- Renovate PRの本文は以下の形式:
```
| Package | Change | Age | Confidence |
|---|---|---|---|
| [io.github.takahirom.roborazzi](...) | `1.52.0` → `1.54.0` | ... | ... |
```
## 3. リリースノートURL解決
- `./references/dependencies-release-notes.json` を読み込み
- 各パッケージ名に対応するリリースノートURLを検索
- マッチングロジック:
- パッケージ名の一部（例: `roborazzi`）でJSONのnameフィールドを検索
- 見つからない場合はPR本文のRelease Notesセクションを使用
## 4. 変更内容確認（リリースノート）
- 解決したURLをWebFetchで取得
- 主要な変更点を抽出:
- **Breaking changes** (破壊的変更)
- **New features** (新機能)
- **Bug fixes** (バグ修正)
- **Deprecations** (非推奨化)
- **Behavior changes** (挙動変更)
## 5. 差分詳細確認（PR/Changelog URL）
PR本文のRelease Notesセクション（`<details>`タグ内）から以下のURLを抽出:
### 抽出対象
- `[Compare Source]` リンク（例: `https://github.com/xxx/compare/v1.0.0...v1.1.0`）
- 個別のPull Request URL（例: `https://github.com/xxx/pull/123` または `#123`）
- CHANGELOG.md へのリンク
- Full Changelog リンク
### 確認内容
- 抽出したURLをWebFetchで取得（主要なもののみ、全てではない）
- 具体的なコード変更内容を理解:
- どのファイル/クラス/関数が変更されたか
- どのAPIが変更/削除されたか
- 移行ガイドがあるか
## 6. 影響分析
### Breaking changesやAPI変更がある場合
- 変更されたAPI名やクラス名でコードベースを検索（Grep）
- 影響を受ける可能性のあるファイルを特定
- 具体的な修正が必要かどうかを判断
### 影響がない場合
- 「影響なし」と記載
## 7. レポート生成・PRコメント投稿
### 重要: `#xxx` 形式の回避
コメント本文内で `#123` のような形式を使用すると、リポジトリのissue/PRにリンクされてしまう。これを回避するため、外部リポジトリのPR/issue番号は以下のいずれかの方法で記載する：
- バッククォートで囲む: `` `#123` ``
- 完全なURLリンクを使用: `[#123](https://github.com/xxx/yyy/pull/123)`
- 括弧付きで記載: `(#123)`→ `` (`#123`) `` のようにバッククォートで囲む
### レポートテンプレート
以下の形式でコメントを生成する:
```markdown
## 📦 依存関係更新レポート
### 更新内容
| パッケージ | 変更 |
|---|---|
| {package} | {old_version} → {new_version} |
### リリースノート要約
{主要な変更点を箇条書き}
### Breaking Changes
{breaking_changes または "なし"}
### 影響分析
{impact_analysis または "影響なし"}
### 推奨アクション
{マージ可 / 要対応 / 要確認}
---
_このレポートは Claude によって自動生成されました_
```
### コメント投稿
- `gh pr comment --repo org/repo {number} --body "{report}"` で投稿
- 投稿完了後、PRのURLを出力して完了を通知
今後の展望
まだスキルの状態なので実行するためには手動で行わなければいけません。今後は、PRが作成されたタイミングで自動的にこのスキルが実行されるようにactionsに組み込みたいと思っています。
Discussion