orchestrate-herdr

herdr をオーケストレーションする

作業を、トラッカーのサブイシューまたはハーネスのプロンプトごとに、herdr が管理するワーカータブ 1 つに振り分けます。コードが関わるタスクでは、テストで裏付けられた完了状態に到達するまで、それぞれを進行させます。あなたはオーケストレーターです。実装は決して行わず、自分のタブを閉じてはいけません。

入力

実行モード — SPEC_REF がある場合は spec、それ以外は references/harness.md に従って harness です。入力を決して推測してはいけません。

• SPEC_REF（spec モード）— 開いているサブイシューがワーカーになる親イシューです。Linear の PRWL-100 / ABC-123、または GitHub のイシュー URL か番号を指定します。スキルの引数（SPEC_REF=...、参照をそのまま指定。従来の SPEC_URL= / PRD_URL= も使用可能）または受付から取得します。
• WORKERS（harness モード）— {label, prompt} のリストです。定義は harness のリファレンスに従います。
• AGENT — ワーカーのランタイムです。その CLI_NAME 起動トークンは PATH チェックとタブラベルに、AGENT_KIND は herdr の --kind に使用します。どちらも references/intake.md から取得し、コマンドの最初のトークンから取得してはいけません。Cursor では値が異なります。
• CODING_CLI — CLI_NAME と、ユーザーが設定した既定の設定または受付で選択した設定に基づく権限モードフラグです。プロンプトを起動引数にしてはいけません（「ルール」を参照）。
• ISOLATION — worktree、branch、shared のいずれかです。これによってワーカーを並列実行できるかが決まります。
• TRACKER / TRACKER_TAG — 記録対象のワークスペーストラッカー（G / L）です。references/tracker-map.md のResolveに従って決定します。同ファイルには、以下の太字のセクション名で参照されるトラッカーごとのコマンドが記載されています。

Factory ステージ。 herdr 上でユーザーが開始した /factory run の場合は、受付ではなく references/factory-stage.md に従います。

ルール

• 帰属表示は一切しません。 プロンプト、コミット、トラッカーのコメント、レポートに、共著者、AI、ツールの帰属を記載してはいけません。

• 実装は決して行いません。 オーケストレーターが行うのは、読み取り、タブの作成、プロンプトの送信、監視、報告だけです。それ以外は何も行いません。

• herdr が管理するタブのみを使用します。 既存の herdr ワークスペース／セッション内に作成してください。ペインの分割、内部サブエージェント、ネストしたコーディングセッションは禁止です。また、CODING_CLI の実行中に、別の CODING_CLI を起動してはいけません。

• 分離方法はユーザーが選び、herdr が実施します。 オーケストレーターの作業ディレクトリを維持します。選択された worktree モードの場合に限り、herdr worktree create を使ってワークツリーを作成し、Git を手作業で操作してはいけません。起動前に受付に従ってプロジェクト所有の配置を確認します。配置がサポートされていない場合、そのワーカーの起動を中止します。branch と shared のタブはオーケストレーターのフォルダーで開始するため、そのフォルダーは割り当てられたリポジトリのチェックアウトでなければなりません。

• 保存済みの ID のみを使用します。 すべての送信、読み取り、監視、フォローアップの呼び出しでは、作成時に保存したタブ ID とエージェント名を使用します。アクティブなタブ、最新のタブ、画面上の順序、推測した値を使ってはいけません。

• プロンプトは準備完了した CLI に貼り付けて送信します。 起動引数／フラグとして渡したり、未送信のまま残したりしてはいけません。また、プロンプトのテキストがコマンドとして実行される、停止したタブのシェルに決して貼り付けてはいけません。

• タブから完了の証拠を読み取ります。 差分がソースまたはテストに触れているタスクでは、ワーカーの説明にかかわらず、テストコマンドと合格を示す出力の引用が必要です。コード以外のタスクでは、プロンプトで指定した証拠、または指定がない場合は確認可能な結果が必要です。spec のタスクでは、すべての基準を網羅する AC map: も必要です。証拠が不足していれば未完了です。要約だけでは主張にすぎません。

• 提案のみとし、自動で連鎖させません。 最終レポートの後、AC map に未対応の行がある各 PR に対して /agentic-qa、ワーカーの差分に対して /code-review、またはリリース内容に対して /release-notes を提案します。提案だけを行い、その後は停止します。

ワークフロー

各フェーズの移行時に、Stage / Found / Next / Needs user を出力します。各フィールドは 1 行ずつ記載します。移行のタイミングは、タブの作成時、プロンプトの送信時、ワーカーのステータスが変わったとき、最終レポート時です。

1. 事前確認

何かを作成する前に、不足している項目を明示してすぐに失敗させます。

1. HERDR_ENV=1 が設定されていること — herdr 内にいる必要があります。設定されていない場合は停止します。
2. すでにコンテキストにない場合は、references/herdr-commands.md の Companion に従って herdr のコンパニオンを読み込みます — バイナリに同梱されているため、これは読み込みであり、ゲートではありません。このファイルには、以下で太字のセクション名を使って参照する herdr コマンドが記載されています。
3. モード： SPEC_REF が存在する場合は spec、存在しない場合は harness です。実行でトラッカー API を使う場合（spec モード、または issue を扱う harness ワーカー）は、Resolve に従って TRACKER / TRACKER_TAG を解決し、そのトラッカーのアクセス確認を実行します。
4. Harness のみ： 定義ステップ後の WORKERS が空の場合は停止します。

2. ワーカーセットの構築

Spec — Discover に従ってオープン中のサブイシューを一覧表示します。タブを作る前に件数を伝え、spec と照合します — ワーカー数が不足するとスライスが漏れます。オープン中のサブイシューをすべて対象にします。ready-for-agent はフィルターとして使いません。各 issue の識別子は <n> です。オープン中の issue がゼロの場合は、Intake の前に停止します。別のオープン中のサブイシューによってブロックされているサブイシューは並列作業ではありません。Discover に従ってペアを一覧表示し、Intake の質問 3 で確認します。

Harness — references/harness.md に従って WORKERS を定義します。タブを作る前に件数を伝えます。

3. Intake

Discover の後に、まとめて質問を一度だけ行います。事前に質問してはいけません — 4 項目のうち 2 項目には issue の一覧が必要です。質問では、影響を受ける issue とリポジトリを明示します。応答がない場合の代替手順と全マトリックスについては、references/intake.md を参照してください。

1. コーディングエージェントの選択。 Intake の一覧に従い、6 種類のランタイムすべてを製品名で提示します。括弧内のトークンは AGENT_KIND です。起動トークンが PATH 上にあるランタイムをすべて提示し、不足しているものも伝えます。単独のバイナリ名だけで選択肢を示してはいけません。
2. 権限モードの選択。 ユーザーがすでに使っている権限モードを再利用します。そうでない場合は、Intake に従って、確認済みの対話型プリセットまたは単独の起動トークンを提示します。選択したモードが CODING_CLI になります。
3. 作業の分離方法。 worktree、branch、shared のいずれかです。オープン中のサブイシューが同じリポジトリを共有する場合は、worktree を推奨します。
4. この spec の前回の実行で残っているタブとエージェントを監視するか、新たに並行して作成するかを確認します。

4. ワーカータブの作成

Context に従って、呼び出し元のワークスペース、タブ、フォルダーを保存します。ワーカーごとに 1 つのタブを作成します。spec → [CLI_NAME] - <TRACKER_TAG> #<n>、harness → [CLI_NAME] - <label>。ISOLATION に応じて、Creating worktrees または Create tab を使います。各ワーカーのコンテキスト、タブ／ペイン ID、エージェント名、確認済みのチェックアウト記録を checkout binding に従って保存します。リポジトリが未解決の場合、またはネイティブの配置先が正しくない場合は、起動できません。

5. ワーカーの起動

時間のかかる作業はタブ間で並列化します。

• Start agent に従ってすべてのワーカーを開始し、AGENT_KIND を --kind として、CODING_CLI のフラグを -- の後に指定します。各呼び出しはエージェントの準備が整うまでブロックするため、並行して実行します。例外は、共有チェックアウトでの branch 分離です。この場合はワーカーを 1 つずつディスパッチします。準備完了を待つためのポーリングやスリープは行いません。agent_not_ready は、承認 UI が直接起動したことを意味します。これを Needs user に報告し、再起動してはいけません。それ以外のエラーは、Monitor で CLI が使用不能なケースとして扱います。
• Submit に従って、その issue のワーカープロンプトを送信します。

タブ ID とエージェント名が保存され、プロンプトが受け付けられ、最初の応答が表示されるまで、ワーカーは起動済みとはみなしません。

Spec： references/worker-prompt.md に従い、ワーカーごとに 1 つの issue を割り当てます。Harness： そのワーカーのプロンプトにフッターとチェックアウトバインディングを追加します。該当する指示と保存済みのチェックアウト記録を渡し、ワーカーが編集前に本人確認とベースラインの確認を行うようにします。必要に応じてローカルレーンを使います。クラウドは使いません。

/tdd-loop を使わないコードワーカーにも、テストの証拠を提示する責任があります。その旨を起動時の更新で伝えます。

6. 監視

Watch に従ってライフサイクル状態を待ちます。ワーカーの処理が完了した瞬間に反応するため、巡回確認は不要です。完了したタブは Read に従って読み取ります。コンテキストの圧縮後または再起動後は、いずれかの呼び出しを行う前に Context に従って復旧します。

• 状態： blocked → 承認または質問の UI です。「ユーザー対応が必要」に表示し、再起動したり回答したりしないでください。idle / done → レポートを確認するため、タブを読み取ります。working → そのままにします。
• 停止状態： unknown は完了の証拠にはなりません。開始、送信、または待機でエラーが発生した後は、再試行する前に状態と出力を確認してください。送信が成功した後にタイムアウトすることもあります。エージェントが消失した場合は、プロセスが終了したことを確認してから、ワーカーの起動を一度やり直します。実行中の長時間テストはそのまま実行させます。無応答だけを理由に blocked と判断してはいけません。観測された失敗または人間による判断待ちがある場合に限り、ブロッカーとして報告します。
• ラベル： トラッカーに割り当てられたワーカーに人間の対応が必要な場合は、Block に従って ready-for-human を付け、判断内容をコメントします。課題のタイトルは編集しないでください（BLOCKER:、AFK:、HITL: マーカーも付けません）。
• 完了： 各タブを Read に従って読み取ります。コードタスクではテストの合格出力を引用し、非コードタスクでは割り当てられたエビデンスを提示します。
• ステータスボード： 状態変化による起動のたびに、件数を1行で表示します — N running · M completed · K blocked/needs-user — 状態が変化したタブがあれば、そのタブ名も記載します。

7. 報告

モード、エージェント、分離方式、ワークスペース／セッション ID、フォルダー、タブの対応表と割り当て、各タブの最終状態、タスクのエビデンス、および AC map / Decisions / Open items（仕様モードでは AC map）を報告します。worktree／branch モードでは、複数のブランチが変更したファイル（git diff --name-only <base>...<branch>）をマージリスクとして列挙します。

完了条件

• 最終的なタブの対応表に、失敗した起動や終了したワーカーを含むセット内のすべてのワーカー（検出されたサブ課題またはハーネスの WORKERS）が記載されている。保存済みの ID と最終状態は、読み返した内容と一致している
• 各タブを読み返すと、送信済みのプロンプトとワーカーの応答が確認できる。ステージング済みまたは未送信のものはない
• 起動した各ワーカーのチェックアウトと指示がプロンプトに一致している。書き込みタスクでは、ベースラインと最初の書き込みを行った主体が報告されている
• worktree または branch モードでは、各ワーカーのコミットがその課題のブランチにのみ反映されている
• すべてのワーカーが、コードタスクのテストエビデンスまたは割り当てられた非コードタスクのエビデンス（仕様では AC map も含む）を伴って完了しているか、ブロック中またはエラーになっている
• ブロックされたトラッカー割り当て済みの課題には、Verify の読み返しで ready-for-human と判断内容を明記したコメントが確認でき、タイトルは変更されていない
• トランスクリプトは最終レポートと /agentic-qa / /code-review / /release-notes の提案で終わっており、その後に何もない