| name | legacy-modernizer |
| description | レガシーコード・大規模システムを止めずに段階的に刷新する戦略を立てるスキル。ストラングラーフィグ・腐敗防止層・characterization test 等のパターンを提案する。「レガシーコードを刷新したい」「段階的にリプレースしたい」「ストラングラーパターンで移行したい」「このモノリスを分割したい」「技術的負債を返済したい」などで発動する。大規模・段階的な移行戦略を扱う。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"planning","tags":["legacy","refactoring","modernization","strangler-fig","technical-debt"]} |
legacy-modernizer
「動いているが触りたくない」コードを、リスクを抑えて段階的に刷新する計画を立てる。一気に書き直す（big bang rewrite）誘惑を避け、常に動く状態を保ちながら少しずつ置き換える。
code-simplifier は1ファイル〜関数の局所的な整理。本スキルはシステム/モジュール規模の移行戦略と順序付けを扱う。
原則
- big bang を避ける — 全面書き直しは高リスク。動く現行と並走させ段階移行する
- 安全網を先に張る — 振る舞いを変えずに済むよう、まず characterization test で現状の挙動を固定する
- 小さく可逆に — 各ステップは小さく、いつでも戻せる単位にする
- 価値の高い所から — 変更頻度×リスクの高い部分を優先する（全部を綺麗にしない）
ワークフロー
Step 1: 現状を把握し的を絞る
- 対象コードベースを調査する（規模・依存・テスト有無・変更頻度）。広域調査は
Explore エージェントの活用も検討
- 痛みの所在を特定: 頻繁に壊れる/触ると怖い/性能が出ない/拡張できない箇所
- 全部やろうとしない。投資対効果の高いターゲットを選ぶ
Step 2: 安全網を張る
- characterization test（現状の振る舞いをそのまま固定するテスト）を先に書く。「正しい」かでなく「今こう動く」を記録する
- seam（縫い目） を見つける/作る — テスト可能にするための差し替えポイント（依存注入・インターフェース抽出）
- テスト戦略は
test-driven-development / webapp-testing と連携する
Step 3: 移行パターンを選ぶ
references/patterns.md から状況に合うものを選ぶ:
| パターン | 使いどころ |
|---|
| ストラングラーフィグ | 新旧を並走させ、機能単位で徐々に新へ振り替える |
| 腐敗防止層 (ACL) | 新コードを旧モデルの汚染から守る変換層 |
| ブランチ・バイ・アブストラクション | 抽象を挟み、裏側を差し替える（長期ブランチを避ける） |
| 並行運用（shadow / 比較実行） | 新旧両方を実行し結果を比較してから切替 |
Step 4: 段階計画を立てる
- 移行を 小さなインクリメントに分解する（
decomposition 連携）。各増分は「リリース可能・可逆」
- 順序付け: 依存の少ない/価値の高いものから。リスクと工数は
estimation で見積もる
- 切替の制御に フィーチャーフラグ、問題時の ロールバック 経路を各増分に用意する
- 各ステップに「完了の定義」と「成功の計測」（
observability-designer）を添える
Step 5: 文書化
移行ロードマップ（フェーズ・対象・パターン・リスク・ロールバック）を表で出力し、mermaid-diagrammer で新旧構成と移行フローを図化する。
ガードレール
| 制限 | 内容 |
|---|
| big bang 抑制 | 全面書き直しは原則勧めない。やむを得ない場合はリスクと代替案を明示する |
| 安全網優先 | テスト無しの大改修を勧めない。characterization test を先行させる |
| 可逆性 | 各ステップにロールバック手段（フラグ・並走）を用意する |
| 範囲の現実性 | 一度に全部を対象にしない。価値の高い部分に絞って段階化する |
