full-codebase-migrator

フルコードベース移行ツール

100 万トークンのコンテキストウィンドウを活用してコードベース全体を取り込み、アーキテクチャをエンドツーエンドで把握し、チームが競合なく順番に実行できる、ファイル単位の包括的な移行計画を作成します。

目次

• references/migration-types.md -- 対応する移行の種類、このスキルを使用するタイミングと使用しないタイミング。
• references/ingestion.md -- アーキテクチャ、glob パターン、メタデータの収集、読み取り順序、コンテキストの予算管理、依存関係グラフの構築（ステップ 0～2）。
• references/workflow-detail.md -- ファイルごとの評価、移行順序、リスクスコアリング、工数見積もりのテンプレート（ステップ 3～6）。
• references/output-template.md -- migration-plan.md と migration-plan.json のテンプレート、エッジケース、最終品質チェックリスト（ステップ 7～8）。

ワークフロー

1. 対象範囲を特定します。移行の種類、対象範囲（リポジトリ全体またはディレクトリ）、migration-plan.md の出力先、除外項目や制約を決定します。ユーザーのプロンプトにすでに指定されている場合は、その内容から推測します。対応する移行の種類と適合性については、references/migration-types.md を参照してください。
2. コードベースを取り込みます。すべてのソースファイルを glob で取得し、Bash でメタデータ（行数、パッケージマニフェスト、設定、Git 履歴、ディレクトリツリー）を収集した後、すべてのソースファイルを読み取ります。ファイル数が 500 以上のコードベースでは、Agent のサブエージェントを起動して、ディレクトリサブツリーを並列で読み取ります。references/ingestion.md を参照してください。
3. 依存関係グラフを構築します。すべての import を抽出し、隣接リストを作成して、各ファイルをレイヤーに分類し、循環依存を検出し、外部依存関係を分類します。references/ingestion.md を参照してください。
4. 各ファイルを評価します。レイヤー、複雑さ、見つかったパターン、必要な変更、前提となる依存関係、リスク要因、テストへの影響を含む、ファイルごとの移行評価を作成します。references/workflow-detail.md を参照してください。
5. 移行順序を算出します。レイヤー順にトポロジカルソートを実行し、実務上の調整（簡単にできる成果、高リスク項目の早期対応、循環依存の先行解消）を加えて、ビルド可能で PR 単位のフェーズにファイルをグループ化します。references/workflow-detail.md を参照してください。
6. リスクを評価します。複雑さ、中心性、変動性、テストカバレッジ、外部との結合度について、各ファイルを 1～5 でスコアリングします。移行レベルのリスクマトリックスとロールバック戦略を作成します。references/workflow-detail.md を参照してください。
7. 工数を見積もります。オーバーヘッドと 20％ のバッファーを加えて、ファイルごと、フェーズごと、および合計の見積もりを算出し、チームの規模に応じてカレンダー上の所要期間に換算します。references/workflow-detail.md と references/migration-types.md の工数調整テーブルを参照してください。
8. 成果物を生成します。出力先に migration-plan.md を書き込み、機械可読形式が役立つ場合は migration-plan.json も作成します。納品前に品質チェックリストに照らして確認します。references/output-template.md を参照してください。

エッジケース

コンテキストに収まらない大規模なコードベース、モノレポ、一部が移行済みのコードベース、テストのないコードベースでは、それぞれ対応を調整する必要があります。references/output-template.md を参照してください。