dependency-upgrader

name	dependency-upgrader
description	ライブラリ・FW・ランタイムのバージョンアップ（特にメジャー/破壊的変更を含む移行）を計画・実行するスキル。移行ガイドやCHANGELOGから破壊的変更を洗い出し、影響特定・codemod・段階適用・検証を提案する。「メジャーバージョンを上げたい」「React 17 から 18 へ移行」「破壊的変更に対応して」「依存を最新化して」などで発動する。バージョン移行の実作業を扱う。
metadata	{"version":"1.0.0","tier":"experimental","category":"maintenance","tags":["dependencies","upgrade","migration","codemod","breaking-changes"]}

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 を根拠に対応する。不明は明示する
検証必須	ビルド・テスト・必要なら手動確認を経てから完了とする