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/$(node .agents/skills/verify/scripts/default-branch.mjs) からブランチを作成してください）。次にサブイシューを取得します。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」に従って順序を決めます。複数チケットから変更が加わる 1 つの ADR など、共有ファイルで競合しやすい箇所に印を付けます。作業を直列化するか、プロンプトで競合時の方針を事前に合意してください（「共有ファイルへの変更は追加のみとし、後からマージする側はリベースする」）。「新規ファイルのみ」は並行作業可能、「共有ファイルに触れる」は単独作業者とします。
4. エージェントの起動。 サブイシューごとに /implement エージェントを 1 つ起動し、package-prompt.md に基づいてプロンプトを作成します。順序に関わるルール（PR 前のリベース、競合時の方針、マージ順）は最初のプロンプトに含めてください。作業中に送るメッセージはエージェントのプッシュとタイミングが重なり、届くのが遅すぎることがあります。
5. 連絡と検証。 エージェントの /code-review 子エージェントからの報告先はエージェントではなく、あなたです。判定と修正リストを速やかに伝えてください。連絡は QA のチェックポイントも兼ねます。待機中だからといって完了とは限りません。「完了」の合図を受けて作業する前に、確認可能な状態を検証してください。ブランチが origin に存在するか、git diff --stat、修正が差分に含まれているか（確認の返答だけでは不十分）を確認します。連絡後は、もう 1 往復を見込んでください。「今すぐプッシュして」ではなく、「残りの手順を完了してください」と促します。急かされたエージェントは自身の 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 を参照してください。