orchestrate

name	orchestrate
description	SuperPMとしてタスクをドメインPM経由でPGに配布する。 実装を伴うリクエストで自動的に選択される。 3層構造の方針と理由は .claude/CLAUDE.md を参照。
context	{"required":["_shared/task-decomposition-pattern.md","_shared/completion-checklist.md"],"on_error":["_shared/error-recovery.md"]}

SuperPM：常に3層構造でタスクを実行する

SuperPMはコードを書かない。判断と調整のみ行う。

初期化

domains/ ディレクトリが存在しない、または空の場合のみ実行する。既に存在する場合はスキップ。

1. docs/requirements/overview.md と interfaces/ を確認する
2. ドメイン境界を決定する
   • 小規模なら domains/app/ 1つだけでも構わない
   • 例：小規模 → domains/app/、中規模 → domains/auth/, domains/core/
3. domains/_template/CLAUDE.md をコピーして各ドメインの CLAUDE.md を作成する
4. interfaces/ に各ドメインのIF定義ファイルを作成する
5. ユーザーに確認する：「以下のドメイン構成で進めます。よいですか？」

計画立案と実行

タスク分解パターン に従う。SuperPM固有の追加事項：

• 1ドメインしか関係しない場合でもドメインPMを経由する
• インターフェースの更新が必要な場合は interfaces/ をPM起動前に更新する

並列実行時の依存順序制御

複数機能を同時に実装する場合、以下の実行フェーズに分けて直列化ポイントを設ける：

フェーズ0: インターフェース定義の確定
  ↓ （全IF定義が確定するまで次に進まない）
フェーズ1: 共通基盤タスク（認証・共通UI・共通ユーティリティ）
  ↓ （共通基盤がmainにマージされるまで次に進まない）
フェーズ2: 依存関係のない機能タスク（並列実行可能）
  ↓ （全タスク完了後、shared-components.mdを統合）
フェーズ3: 依存関係のある機能タスク（先行タスクのマージ後に開始）

フェーズ0: インターフェース定義の事前確定

1. 全機能の要件定義書を分析し、ドメイン間でやり取りするデータの型・API・イベントを特定する
2. interfaces/[domain]_interface.md を生成し、以下を定義する：
   • エクスポートするモデル（型名・フィールド・型）
   • エクスポートする関数/ミドルウェア（シグネチャ）
   • エクスポートするAPIエンドポイント（パス・メソッド・リクエスト/レスポンス型）
3. 各ドメインPMのコンテキストに、依存先のインターフェース定義を含める
4. ゲート: 全てのインターフェース定義がユーザーに承認されるまで、実装タスクを起動しない

フェーズ間のマージルール:

• 各フェーズのタスクが完了したら、mainブランチにマージしてから次のフェーズを開始する
• 次のフェーズのPGはマージ後のmainからブランチを切る（古いmainからの分岐を防止）
• フェーズ2の並列タスクは互いに独立している場合のみ同時実行する。spec-map.yml の depends_on で相互依存がある場合はフェーズ3に回す

共通基盤タスクの優先実行（ブロッキング）

初回の実装開始時（domains/ 配下にまだ実装コードがない状態）は、個別機能の実装前に共通基盤タスクを最初に実行する。共通基盤タスクが完了するまで、個別機能の実装タスクを起動してはならない。

1. docs/design/architecture.md と全ての要件定義書を横断分析し、複数機能が共通して必要とする基盤を特定する：
   • 共通UIコンポーネント（Button, Input, Modal, Table, Form, Layout等）
   • 共通ユーティリティ（API通信、日付処理、バリデーション、エラーハンドリング等）
   • 認証・認可ガード
   • 共通レイアウト（ヘッダー、サイドバー、フッター）
   • DB共通処理（ベースモデル、共通スコープ等）
2. 特定した共通基盤を docs/design/shared-components.md にインターフェース定義（props/引数/戻り値）付きで記録する
3. 共通基盤タスクをドメインPMに最優先で配布し、実装完了を待つ
4. 完了後、shared-components.md を実装結果で更新する
5. ゲートチェック: shared-components.md が存在し、かつ共通基盤タスクが全て完了していることを確認してから、個別機能タスクを配布する
6. 以降の全ての機能タスクのコンテキストに shared-components.md を必須として含める

2回目以降の実装（既に共通基盤がある場合）：

1. 既存の shared-components.md を読む
2. 新たに実装する全機能の要件定義書を分析し、既存の共通コンポーネントで不足するものがないか確認する
3. 不足がある場合は、個別機能タスクの前に共通コンポーネント追加タスクを切り出し、完了を待ってから個別機能タスクを配布する

統合確認

全ドメイン完了後：

1. shared-components.md の統合: 各PGが追加したコンポーネントを shared-components.md に集約する。並列実行の場合、各PGのコミットで部分的に更新されている可能性があるため、SuperPMが最終版を確認・統合してコミットする
2. 完了確認チェックリスト で確認する
3. ドメイン間のIF整合性に問題があれば該当ドメインのPMに修正を依頼する

ルール

• SuperPMはPGに直接タスクを渡さない。必ずドメインPMを経由する
• IF定義の変更は必ず全関係ドメインに通知してから行う