orchestrate

worktree 上で、事前に仕様化された機能を並列の /implement サブエージェントに実装させます。

ルール 0

作業を自分で分割したり、割り当てを決めたりしてはいけません。親イシューのサブイシューが作業パッケージです。サブイシューを取得し、それぞれを一字一句そのまま 1 つの /implement エージェントに渡してください。サブイシューが存在しない、または内容が不明確な場合は、作業を止めてオーナーに確認してください。作業パッケージを独自に考案してはいけません。プロセスへの忠実さは必須です。事前に仕様化された手順を外れて成果物を作成した場合、成果物が正しくても却下されます。

役割

• オーケストレーター（あなた）：読み取り専用操作、gh の使用、エージェントの起動のみを行います。src/ は編集しません。担当するのは、順序決め、連絡の中継、各フェーズ間の検証、マージ、クリーンアップ、運用サイドカー（ops.md を参照）です。
• エージェント：ネイティブなクレーム、独自の worktree、TDD、/code-review、自分の PR 作成までを含む、完全な /implement フローを実行します。これらをここで重複して行ってはいけません。
• 機械的な後処理（マージ順、CI の監視、ブランチ／worktree のクリーンアップ）はオーケストレーターが担当します。エージェントの作業は「PR 作成＋報告」で終了します。

台帳

GitHub イシューが台帳です。オーナー不在の状態で関連する出来事があった場合や判断を下した場合は、要約したコメントを投稿してください。オーケストレーターは親イシューに、各エージェントは担当のサブイシューに投稿します。

🤖 decision (bot): <one line>
<2–4 lines: why, link>

種別：decision | question | blocker | progress。必ず 🤖 のプレフィックスを付け、判断には明示的に (bot) と記してください。gh issue comment N --body-file .temp/<f>.md で投稿します（heredoc はブロックされています）。質問はイシューに投稿し、許容可能な既定の選択肢がある場合は作業を続行してください。質問で作業を止めてはいけません。

実行手順

1. 同期とサブイシューの取得。 git fetch && git pull --ff-only（メインのチェックアウトではブランチがずれているため、git branch --show-current で確認してください。常に origin/main からブランチを作成してください）。次にサブイシューを取得します。サブイシューは GraphQL でのみ取得でき、gh issue view には表示されません。

   gh api graphql -f query='query{ repository(owner:"$OWNER",name:"$REPO"){ issue(number:$N){ subIssues(first:50){ nodes{ number title state } } } } }'
   

   GitHub の機能がないと、CLI の出力だけで判断しないでください。完了条件：すべてのサブイシューが「Blocked by」の依存関係とともに一覧表示されているか、担当者に確認を依頼していること。
2. 調査と実現可能性の確認。 境界となるファイルは自分で読み込んでください。エージェントの要約では API の不足が見落とされます。影響を受けるパッケージの作業を開始する前に、仕様と現在の動作の差分を確認してください。仕様が AI によって作成されている場合があります。Webhook、OAuth アプリ、DNS、サードパーティーの設定など、外部で一度だけ行う設定手順は、エージェントがドキュメントに記載する前に、最新のプロバイダードキュメントで検証してください。たとえば、Webhook に必要なのはトークンではなく SECRET です。また、projects_v2_item イベントは組織の Webhook でのみ使用できます。不足があれば、台帳に question として記録します。完了条件：外部に関する前提がすべて検証済みか、台帳に記録されていること。
3. 順序とホットスポット。 各チケットの「Blocked by」に基づいて順序を決めます。複数のチケットから変更が入る ADR など、複数人が同じファイルを編集する箇所を特定してください。順番に処理するか、プロンプトで競合時の方針を事前に合意します（「共有ファイルへの変更は追加のみとする。後からマージする側はリベースする」）。「新規ファイルのみ」なら並行作業が可能です。「共有ファイルを変更する」なら作業者を一人にします。
4. エージェントの起動。 サブイシューごとに /implement エージェントを1つ起動し、package-prompt.md に基づいてプロンプトを作成します。順序に関わるルール（PR 前のリベース、競合時の方針、マージ順）は最初のプロンプトに含めてください。作業途中のメッセージはエージェントのプッシュと行き違い、遅すぎる可能性があります。
5. 連絡と検証。 エージェントの /code-review 子エージェントは、エージェントではなくあなたに報告します。判定と修正リストを速やかに伝えてください。連絡のやり取りは QA のチェックポイントも兼ねます。待機中だから完了とは限りません。「完了」の合図を受けたら行動する前に、確認可能な状態を検証してください。ブランチが origin にあること、git diff --stat、修正が確認メッセージだけでなく差分に含まれていることを確認します。連絡の後は、もう一度やり取りがあると想定してください。「今すぐプッシュして」ではなく「残りの手順を完了してください」と促します。急かされたエージェントは自分の QA を省略します。
6. マージ。 CI がすべて成功した場合に限り、gh run watch <id> --exit-status && gh pr merge <n> --squash --delete-branch && <cleanup> を1つのバックグラウンド呼び出しで連結して実行します。マージ順はあなたが管理し、後からマージする側はリベースします。完了条件：各サブイシューに対して、Closes #<sub> を含むマージ済み PR がちょうど1つあること。
7. 締めくくり。 共有行に関するドキュメント（現時点では CLAUDE.md）向けに、最後にドキュメント PR を1つ作成します。チケットごとに作成してはいけません。アクセスできないインフラ上のブロッカー（Neon／Vercel のコンソールはオーナーのみアクセス可能）は、正当な終了状態です。根拠とオーナーに必要な対応を添えて、PR の台帳に blocker として記録してください。親イシューに最後の 🤖 集計を投稿します。

過去の実行のアーカイブからの復旧、デプロイの診断、Projects v2 の制限、破壊的なスクリプトのルールについては、ops.md を参照してください。