# Dependency Upgrader

> ライブラリ・FW・ランタイムのバージョンアップ（特にメジャー/破壊的変更を含む移行）を計画・実行するスキル。移行ガイドやCHANGELOGから破壊的変更を洗い出し、影響特定・codemod・段階適用・検証を提案する。「メジャーバージョンを上げたい」「React 17 から 18 へ移行」「破壊的変更に対応して」「依存を最新化して」などで発動する。バージョン移行の実作業を扱う。

- Skill: `ynitto/dependency-upgrader` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ynitto/dependency-upgrader`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ynitto/dependency-upgrader/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: ynitto (https://skillmd.com/u/ynitto)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ynitto/dependency-upgrader

---


# dependency-upgrader

依存（ライブラリ・FW・ランタイム）のバージョンアップを、破壊的変更を取りこぼさず段階的に進める。「とりあえず上げて壊れたら直す」ではなく、変更点を把握してから計画的に移行する。

> `dependency-auditor` は脆弱性・ライセンスの監査。本スキルは「上げる」実作業（破壊的変更対応・検証）を担う。

## 原則

- **変更点を先に読む** — 移行ガイド・CHANGELOG・破壊的変更リストを把握してから着手する
- **一度に一つ** — 複数の大型アップグレードを混ぜない。問題の切り分けを保つ
- **段階的に** — 飛び級より、メジャーを一段ずつ。各段で動作確認する
- **テストで守る** — アップグレード前にテストが緑であることを確認し、それを回帰検出に使う

## ワークフロー

### Step 1: 現状と目標を把握する

1. 対象依存・現行バージョン・目標バージョンを確認する（`package.json`/`go.mod`/`requirements.txt`/`pom.xml` 等）
2. アップグレードの動機を確認: 脆弱性対応 / 新機能 / サポート終了(EOL) / 他依存との互換
3. 現状テストが通ることを確認する（無ければ重要経路に安全網を先に張る → `legacy-modernizer` の characterization test）

### Step 2: 破壊的変更を調査する

- 公式の **migration guide / upgrade guide / CHANGELOG / release notes** を確認する（必要に応じ `WebSearch`/`WebFetch`）
- メジャーを跨ぐ場合、間の各メジャーの破壊的変更も累積で拾う
- 破壊的変更を「削除されたAPI」「シグネチャ変更」「デフォルト挙動変更」「設定/ビルド変更」に分類する

### Step 3: 影響箇所を特定する

- 廃止/変更された API の使用箇所をコード検索で洗い出す（`Grep`/`Explore`）
- 推移的依存（間接依存）への波及、ピア依存の整合も確認する
- 影響範囲から工数・リスクを `estimation` で見積もる

### Step 4: 段階的に適用する

- **codemod があれば活用**: 公式が提供する自動変換（例: React の `react-codemod`、`jscodeshift`、各FWのCLI）で機械的変更を一括適用
- メジャーは一段ずつ上げ、各段でビルド・テスト・型チェックを回す
- 大規模なら `legacy-modernizer` のブランチ・バイ・アブストラクションやフラグで段階移行
- 変更はテーマ単位でコミット分割し、レビュー可能に（`commit-pr-writer` 連携）

### Step 5: 検証する

1. ビルド・型チェック・リンタ・テストスイートを実行する
2. 非推奨警告（deprecation warning）を確認し、次のアップグレードに備えて潰す
3. 挙動変更があり得る箇所は手動/E2E で確認（`webapp-testing`/`bruno-e2e-builder`）
4. ロックファイルを更新し、再現可能性を担保する

### Step 6: 文書化

破壊的変更と対応内容、残課題（次に対応すべき非推奨）、ロールバック手順を PR 説明にまとめる。

## ガードレール

| 制限 | 内容 |
|------|------|
| 一度に一つ | 複数の大型アップグレードを同時に行わない（切り分け不能を防ぐ） |
| 段階適用 | メジャーの飛び級を避け、一段ずつ検証する |
| 安全網 | テストが無い状態での大型アップグレードを勧めない |
| 推測で直さない | 破壊的変更は公式ガイド/CHANGELOG を根拠に対応する。不明は明示する |
| 検証必須 | ビルド・テスト・必要なら手動確認を経てから完了とする |