orchestrate-batch-refactor

バッチリファクタリングのオーケストレーション

概要

このスキルを使って、大規模なリファクタリングを安全に実行します。 スコープを並列で分析し、単一の計画にまとめてから、サブエージェントを使って独立した作業パケットを実行します。

入力

• リポジトリのパスと対象スコープ（パス、モジュール、または機能領域）
• 目的の種類：リファクタリング、書き換え、またはその併用
• 制約：動作の同等性、API の安定性、期限、テスト要件

並列化するタイミング

• 多数のファイルやサブシステムに及ぶ中規模から大規模なスコープでは、このスキルを使います。
• 小規模な編集や、単一ファイル内で密接に結合した作業では、マルチエージェントによる実行を避けます。

基本的なワークフロー

1. スコープと成功基準を定義します。
   • 対象のパス／モジュールと、対象外の項目を列挙します。
   • 動作に関する制約（例：外部から見た動作を維持する）を明記します。
2. まず並列で分析します。
   • 対象スコープを分析レーンに分割します。
   • 各レーンを分析するため、explorer サブエージェントを並列で起動します。
   • 各エージェントには、意図のマップ、結合リスク、作業パケットの候補、必要な検証を求めます。
3. 依存関係を考慮した計画を1つ作成します。
   • explorer の出力を統合し、単一の作業グラフを作成します。
   • ファイルの担当範囲と検証コマンドが明確な作業パケットを作成します。
   • パケットを依存関係のレベルごとに並べ、独立したパケットのみを並列で実行します。
4. ワーカーエージェントで実行します。
   • 独立した各パケットにつき、worker を1つ起動します。
   • 担当範囲（ファイル／責任）を明確に割り当てます。
   • すべてのワーカーに、コードベースで作業しているのは自分だけではなく、無関係な編集は無視するよう指示します。
5. 統合して検証します。
   • パケットの成果を確認し、重複を解決して、検証ゲートを実行します。
   • パケットごとに対象を絞ったテストを実行し、その後、統合したスコープに対してより広範なテストスイートを実行します。
6. 報告して完了します。
   • パケットごとの成果、主なリファクタリング、解決した競合、残るリスクをまとめます。

作業パケットのルール

• 実行ウェーブごとに、各ファイルの担当者を1人にします。
• ファイルセットが重複する編集を並列で行わないでください。
• パケットの目標は、範囲を絞り、測定可能なものにします。
• 完了基準と必須チェックを明記します。
• ユーザーが動作変更を明示的に求めていない限り、動作を維持するリファクタリングを優先します。

計画の要件

各パケットには、次の項目を含める必要があります。

1. パケット ID と目的。
2. 担当ファイル。
3. 依存関係（なし、またはパケット ID）。
4. リスクと維持すべき不変条件。
5. 必須チェック。
6. メインスレッド向けの統合メモ。

正確な形式については、references/work-packet-template.md を使用してください。

エージェントへの指示の要件

• references/agent-prompt-templates.md のプロンプトテンプレートを使用します。
• Explorer へのプロンプトでは、分析と分解に重点を置きます。
• Worker へのプロンプトでは、担当範囲を厳密に守った実装と検証に重点を置きます。

安全対策

• 計画の統合が完了する前に、ワーカーによる実行を開始しないでください。
• 未解決の依存関係をまたいで並列化しないでください。
• 必須のパケットチェックが1つでも失敗した場合、完了したと主張しないでください。
• パケットの境界が原因でマージ競合が繰り返し発生する場合は、作業を止めて計画を立て直してください。

検証戦略

次の順番で実行します。

1. パケット単位のチェック（高速で範囲を限定）。
2. パケット間の統合チェック。
3. スコープが広い場合は、プロジェクト全体の安全性チェック。

フィードバックを素早く得られるサイクルを優先しますが、必須の動作チェックは決して省略しないでください。