mcpField
G
gathering-migration

gathering-migration

github.com/autumnsgrove開発664 回インストール5 日前に更新
リポジトリ

gathering-migration について

gathering-migrationは、複雑なコードベース移行向けのエージェントスキルです。指揮役が調査と移行を別々のサブエージェントに委ね、引き継ぎ時と完了時に検証します。

主な機能

  1. 01移行範囲とロールバック計画の定義
  2. 02独立したBloodhoundによる依存関係の調査
  3. 03Bearによる段階的な移行
  4. 04引き継ぎごとのゲートと結果検証
  5. 05件数、整合性、CIの確認

活用シーン

  1. 01複数ファイルにまたがるコンポーネントやAPIの移行
  2. 02複数の関係に影響するスキーマ変更
  3. 03アイコン、アセット、コンテンツの移行
  4. 04移行範囲が不明なコードベースの調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/autumnsgrove/lattice --skill gathering-migration

インストール後、Claude Code で/gathering-migrationを入力して読み込まれたか確認します。

同梱ファイルreferences/conductor-dispatch.md

詳細

移行の集い 🌲🐻🐕

太鼓の音が谷間に響きます。指揮者は峠に立ち、まったく異なる二つの力を操ります。まずブラッドハウンドが新鮮な目で到着します。何がつながっているかについて先入観はなく、依存関係を嗅ぎ分ける鼻だけを頼りにします。次にクマが目を覚まし、自分では描いていない地図を受け取ります。近道をしたり、「どこに何があるかはもう分かっている」と思い込んだりはしません。それぞれが隔離されたコンテキストを持ち、自分で確かめたことだけを信頼しながら、力を合わせて安全に山を動かします。

招集するタイミング

  • 実行前にコードベースの調査が必要な複雑な移行
  • システム、ライブラリ、アーキテクチャパターン間の移行
  • 複数の関連項目に影響するスキーマ変更
  • 多数のファイルにまたがるコンポーネントや API の移行
  • 下流の依存関係があるアイコン、アセット、コンテンツの移行
  • 移行を始める前に対象領域を把握する必要があるすべての移行

重要: この集いは指揮役です。調査も移行も直接行いません。動物ごとに 1 つずつサブエージェントを派遣し、それぞれに隔離されたコンテキストと意図的に選んだモデルを割り当てます。指揮役は引き継ぎとゲートチェックのみを管理します。


集い

SUMMON → DISPATCH → GATE → DISPATCH → GATE → VERIFY
  ↓         ↓        ↓        ↓        ↓        ↓
Spec    Bloodhound  Check    Bear    Check    Final
(self)   (haiku)     ✓     (opus)    ✓     Verify
派遣する動物
順番動物モデル役割新鮮な目?
1🐕 ブラッドハウンドhaiku依存関係を調査し、対象領域をマッピングするはい — 移行仕様のみを見る
2🐻 クマopus移行を安全に実行するはい — 調査プロセスではなく、対象領域のマップのみを見る

参照: 正確なサブエージェントへのプロンプトと引き継ぎ形式については、references/conductor-dispatch.md を読み込んでください。


フェーズ 1:招集

太鼓が鳴り、谷が耳を澄ませます……

指揮役は移行の依頼を受け取り、派遣計画を準備します。

移行内容を明確にする:

  • 何を移行する必要がありますか?(データ、コンポーネント、アイコン、設定、規約など)
  • どこからどこへ移行しますか?(古いパターン → 新しいパターン)
  • どのような下流の依存関係がありますか?
  • 問題が起きた場合、「元に戻す」とはどういう状態ですか?

クマのドメインガイドを決める:

移行の種類ドメインガイド
データベーススキーマ、テーブル、D1/SQLitedomain-database.md
コンポーネントの props、API のアップグレード、インポートdomain-components.md
アイコン、アセット、ドキュメント、ファイル形式domain-content.md
設定、規約、依存関係domain-general.md

人間に確認してから、先へ進んでください。

出力: 移行仕様、特定したドメインガイド、確認済みの派遣計画。


フェーズ 2:調査(ブラッドハウンド)

指揮役が合図し、ブラッドハウンドが地面に鼻を近づけます……

Agent(bloodhound, model: haiku)
  Input:  migration specification only
  Reads:  bloodhound-scout/SKILL.md (MANDATORY)
  Output: territory map

コードベースを調査するため、haiku サブエージェントを派遣します。ブラッドハウンドが受け取るのは移行仕様のみです。事前分析も先入観もありません。自分のスキルファイルを読み込み、SCENT → TRACK → HUNT → REPORT → RETURN のワークフローを最後まで実行します。

ブラッドハウンドがマッピングする内容:

  • 移行対象へのすべての参照
  • 依存関係(何が何に依存しているか)
  • 下流の利用者
  • エッジケースや通常とは異なる使用パターン
  • 現状の件数(項目数、参照数)

指揮役への引き継ぎ: 対象領域のマップ(影響を受けるファイル、依存関係グラフ、エッジケース、現状の件数、リスク評価)。

ゲートチェック: 対象領域のマップに、ファイル一覧、依存関係、項目数、特定されたエッジケースが含まれていること。不完全な場合は、具体的な質問を添えてブラッドハウンドを再開します。


フェーズ 3:MIGRATE(Bear)

Bear が目を覚まします。Bear が描いたのではない地図を受け取ります……

Agent(bear, model: opus)
  Input:  migration spec + territory map (from Bloodhound)
  Reads:  bear-migrate/SKILL.md + references/{domain-guide} (MANDATORY)
  Output: migration results + file list

移行を実行するために、opus subagent をディスパッチします。Bear が受け取るのは仕様と Bloodhound の領域マップです。Bloodhound の偵察プロセスではなく、構造化された出力のみを受け取ります。

Bear が行うこと:

  • 元の状態を保持する(ブランチ、バックアップ、またはスナップショット)
  • 管理しやすい単位に分けて移行を実行する
  • 各単位の実行後に検証する
  • 項目数が一致することを確認する(移行元と移行先)
  • 整合性チェックを実行する(参照先が解決できる、インポートが機能する、孤立項目がない)

conductor への引き継ぎ: 移行結果(移行した項目、スキップした項目、検証レポート)、ファイル一覧。

ゲートチェック:

pnpm install
gw dev ci --affected --fail-fast --diagnose

コンパイルとテストに合格する必要があります。失敗した場合は、エラーを添えて Bear を再開します。


フェーズ 4:VERIFY

旅が終わります。conductor が安全に到着したことを確認します……

検証チェックリスト:

  • Bloodhound:すべての依存関係がマッピングされている
  • Bloodhound:すべての参照が見つかっている
  • Bloodhound:エッジケースが記録されている
  • Bear:元の状態が保持されている(ブランチ、バックアップ、またはスナップショット)
  • Bear:項目数が一致している(移行元と移行先)
  • Bear:整合性チェックに合格している(参照先が解決できる、インポートが機能する、孤立項目がない)
  • Bear:テストに合格している(gw dev ci --affected)
  • Bear:ロールバック手順が記録されている

完了レポート:

🌲 GATHERING MIGRATION COMPLETE

Migration: [Description]

DISPATCH LOG
  🐕 Bloodhound (haiku) — [territory mapped, X files identified, Y dependencies found]
  🐻 Bear (opus)         — [Z items migrated, domain guide: {guide}]

GATE LOG
  After Bloodhound: ✅ territory map complete
  After Bear:       ✅ compiles clean, migration verified
  Final CI:         ✅ gw dev ci --affected passes

MIGRATION RESULTS
  Items migrated: [count]
  Items skipped: [count, reason]
  Item count match: ✅ [source] = [dest]
  Integrity checks: ✅
  Rollback: [branch/backup location]

Everything found its new home.

Conductor のルール

動物の作業は決して行わない

conductor はディスパッチします。依存関係を偵察したり、移行を実行したりはしません。

新鮮な視点は強みです

Bear が受け取るのは Bloodhound の偵察プロセスではなく、領域マップです。マップを信頼しつつ、移行中に見つけた内容を検証します。

遷移ごとにゲートを設ける

Bear が作業を開始する前に、領域マップを完成させる必要があります。Bear の作業完了後には CI に合格する必要があります。

再開し、やり直さない

ゲートチェックに失敗した場合は、失敗したエージェントを再開します。特に Bear は再開による効果が大きく、移行のコンテキストを保持しているため、最初からやり直すよりも迅速に問題を修正できます。


アンチパターン

conductor が行ってはならないこと:

  • 自らコードベースを偵察する
  • 移行手順を直接実行する
  • 完全な領域マップがない状態で Bear に作業を開始させる
  • 件数の検証を省略する(移行元と移行先の数は一致する必要があります)
  • ロールバック手順の記録を省略する

すばやく判断するためのガイド

移行範囲戦略
単純な名前変更(5 ファイル未満)Bear のみ(Bloodhound は不要)
横断的な移行(5〜50 ファイル)標準:Bloodhound → Bear
大規模な移行(50 ファイル以上)Bloodhound → Bear、分割実行
範囲が不明(「X を移行」)常に Bloodhound から開始

どの動物も単独では不十分なとき、集いが答えを導きます。 🌲🐾

コメント