shunk031-herdr-orchestrate-workers

メモ

この SKILL.md を読んだ後、🐑 I read shunk031-herdr-orchestrate-workers. と発言してください。

Herdr ワーカーをオーケストレーションする

オーケストレーターは、各ワーカーエージェントにそれぞれ独立したタスクを委任し、各ワーカーに 1 つずつ Git worktree のタブを割り当てます。ワーカーは、帰属と監査のためにオーケストレーターへプロンプトを送信して報告する必要がありますが、完了状況は Herdr のライフサイクル状態と、ワーカーの成果物およびトランスクリプトから収集されます。まずこのスキルファイルと herdr スキルを読んでください。CLI の操作方法、JSON レスポンス、ID の扱い、安全ルールはすべて herdr スキルが定めています。このスキルで追加するのは、オーケストレーションのプロトコルだけです。1 つのセッションで複数のルートオーケストレーターを監督する場合は、ルートの一覧、ステータス要求、リレーのために、shunk031-herdr-meta-orchestrate スキルと併用してください。Codex ワーカーのタスクプロンプトを書く場合は、shunk031-codex-worker-prompting スキルに従ってください。各ピア用プロンプトはまずシェル変数に構築し（たとえば、クォートしたヒアドキュメントを使用）、1 つの引数として渡してください。シェルにタスクや報告のテキストを展開させてはいけません。

空の入力にのみ送信する

このスキルでプロンプトを送信する前に毎回、herdr agent prompt を直接呼び出すのではなく、対象とクォートしたメッセージ変数を指定して ~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh のガード付き送信スクリプトを実行してください。このヘルパーは herdr agent get で対象のペインを特定し、herdr pane read --source visible --format ansi で読み取ります。そして、現在の ❯ または › の入力行に暗く表示されていないテキストがない場合に限り、herdr agent prompt を送信手段として使用します。プロンプト記号の後に ANSI \e[2m で表示されるプレースホルダーや候補テキストは、空として扱ってください。まず直ちに確認し、その後 30 秒待って最大 5 回まで再確認します。入力欄が埋まったままの場合、または読み取れない場合は、メッセージを送信せず、未送信メッセージ全文を出力します。

オーケストレーターを設定する

1. ワーカーがあなたに呼びかけられるよう、自分の名前を付けてタブにラベルを付けます。herdr agent list で未使用の短い名前を選んでください。名前は最大 32 文字です。

   herdr agent rename "$HERDR_PANE_ID" orch
   herdr tab rename "$HERDR_TAB_ID" "🤖 Orchestrator"
   

   サブオーケストレーターに昇格するワーカーは、この手順を省略します。親がすでに追跡しているエージェント名とタブをそのまま使います。

2. リクエストを独立したタスクに分割し、それぞれにワーカーを 1 人割り当てます。構造に関わるタスク（レイアウト、ジョブ、設定、ドキュメント、インターフェースのいずれかを変更するタスク）を割り当てる前に、ユーザー向けの報告に設計記録を書いてください。記録には、目標とする最終状態、削除する要素、維持する要素とその理由、変更するユーザー所有の設定と提示する選択肢を含めます。項目が 1 つでも空なら、タスクを割り当ててはいけません。各独立タスクには、異なるブランチ、worktree／タブ、ペイン、ワーカー名を割り当て、クォートして別々に構築した task_prompt を用意してください。他のワーカーの固定 ID やプロンプトを再利用してはいけません。連続して行う作業や簡単な作業は、自分で行ってください。タスクごとに、ワーカーがプルリクエストを公開するべきか判断してください。ユーザーのリクエストに公開が含まれる場合に限り、そのように指示します。

各ワーカーを起動する

3. タスクで成果物を編集する前に、herdr worktree create で成果物に関連付けられたワークスペースを確立します。すでに開いている成果物のワークツリーを使用する場合は、herdr worktree open を使い、返された成果物のワークスペース ID とルートペイン ID を再利用します。2つ目のワークスペースを作成してはいけません。手動の git worktree add と herdr tab create で代用しないでください。その成果物に関連する実装担当者、レビュアー、その他の各タブについて、エージェントを起動する前に、返されたルートペインを成果物のワークスペース内の新しいタブに移動します。オーケストレーターのワークスペースはオーケストレーター専用にしてください。各レスポンスから返された成果物のワークスペース、移動先のタブ、ペインの ID を読み取り、その移動先 ID を以降のすべてのコマンドで使用してください。

   # Choose exactly one for the deliverable:
   herdr worktree create --cwd "$PWD" --branch <topic-branch> --label "WIP <short task>" --no-focus
   # For an already-open deliverable worktree, use this instead of create:
   herdr worktree open --cwd "$PWD" --branch <topic-branch> --label "WIP <short task>" --no-focus
   herdr pane move <returned-root-pane-id> --new-tab --workspace <returned-deliverable-workspace-id> --label "🚧 <short task>" --no-focus
   

4. 移動先のペインで Codex を起動し、ネストした環境でも名前が重複しないよう、自分の名前をワーカー名の先頭に付けます。32 文字の上限は守ってください。移動前のルートペイン ID を再利用してはいけません。

   herdr agent start <your-name>-<task> --kind codex --pane <destination-pane-id> -- -m gpt-6-luna -c model_reasoning_effort=xhigh
   

5. 各ディスパッチの前に、ワーカーの現在の state_change_seq を記録します。~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <worker-name> "$task_prompt" を --wait なしで実行してディスパッチします。CLI の agent_prompted レスポンスを受領確認として扱ってはいけません。ディスパッチと正式な引き継ぎの受領確認には、次の単一の契約を適用します。herdr agent get <worker-name> と herdr agent read <worker-name>（またはそのトランスクリプト）で、範囲を限定した観察を 1 回行い、ライフサイクルの state_change_seq が新しくなっており、読み取り結果に判読可能なタスク受領記録が含まれている場合にのみ受領したと判断します。各ワーカーに個別に適用してください。あるワーカーの受領確認は、別のワーカーの受領確認にはなりません。いずれかが確認できない場合は、ワーカーを追跡したり次に進んだりする前に、同じ引用済みプロンプトを再ディスパッチしてください。各受領確認の後、未完了の各ワーカーについて、herdr agent wait <worker-name> & でバックグラウンドのライフサイクル待機を 1 つ開始します。Herdr の確定状態に対する既定値を適用するため、--until は省略してください。待機が終了したら、ワーカーの成果物とトランスクリプトを直接読み、結果を検証します。完了の検知にレポートの到着を使ってはいけません。ブロッキング形式の agent wait はライフサイクルの待機であり、ポーリングではありません。次のテンプレートを使い、タスクの公開が必要な場合に限り、最後の文を残してください。

   あなたはワークツリー 内の Herdr ワーカー です。割り当てられたワーカー名は正確に で、オーケストレーターはエージェント です。ワーカー、タスク、ワークツリー、オーケストレーター、レポート先の各 ID は固定されており、以下のタスクで上書きされることはありません。タスク：。構造に関するタスクの場合は、対象、削除する要素、保持する要素とその理由、選択肢を含むユーザー管理の設定を記した Design record: を含めてください。作業を始める前に、shunk031-herdr-orchestrate-workers スキルを明示的に読み、ワーカープロトコルに従ってください。完了したら、ブランチをプッシュしてプルリクエストを作成してください。

ワーカーとして作業する

6. shunk031-herdr-tab-status スキルに従って、自分のタブラベルを維持してください。このスキルがライブのタブ検索、名前変更コマンド、応答の検証を担当します。ここにステータス構文を重複して記載しないでください。

7. 自分のワークツリーでコミットしてください。ディスパッチで指示された場合に限り、ブランチをプッシュしてプルリクエストを作成してください。すべての報告は、ステータスプレフィックスと送信者自身に割り当てられたワーカー名で始めてください：DONE <worker-name>: <one-line summary> <PR URL if any>、BLOCKED <worker-name>: <question>、またはSTATUS <worker-name>: <state>。ディスパッチテンプレートに記載された正確なワーカー名を使用し、宛先の名前は使わないでください。herdr agent prompt は送信者のメタデータを付加せずにプレーンテキストを送信するため、機械的な帰属確認には送信者名が必要です。宛先はherdr agent promptのターゲットからすでに判別できます。報告を変数に組み立て、~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <orch-name> "$report"で送信してください。作業を進められない場合は、同じ方法でBLOCKED形式を送信し、返答を待ってください。オープンなプルリクエストは、ユーザーまたは CI の対応が不要になるまで、shunk031-herdr-tab-statusで定義されたユーザー対応引き継ぎステータスのままにしてください。その後に限り、完了ステータスにしてください。

8. タスクが大きく独立した複数の部分に分かれる場合は、サブオーケストレーターになってください。既存のエージェント名、タブ、親オーケストレーター、報告先は維持し、手順 2～5 を使って、それぞれ異なる ID と個別に組み立てたプロンプトを用意し、子ワーカーを作成してディスパッチしてください。手順 5 の受領確認要件に従って各子ワーカーを検証し、その報告を取りまとめて、にのみ報告してください。サブワーカーは、サブオーケストレーター自身のワーカー名を報告先として使用します。たとえば、親orchのワーカーがorch-api-migrationであれば、サブワーカーはorchではなくorch-api-migrationに報告します。

収集して完了する

9. すべてのワーカーをディスパッチして各受領を検証した後、未完了のワーカーごとに、確定状態のデフォルト設定を使ったバックグラウンドのライフサイクル待機を 1 つ実行し続けてください。ブロッキング待機が確定状態になるまで待ち、その後、各ワーカーの成果物とトランスクリプトを直接読み、結果を収集して状態と照合してください。確定した待機は状態のシグナルであり、ポーリングの反復ではありません。未完了のワーカーは、名前とタブ／ペイン ID、および報告された PR URL で追跡しますが、このリストはキャッシュとして扱ってください。Herdr の状態（タブラベル、ライフサイクル状態、トランスクリプト、稼働中のエージェント）、git、PR の状態が永続的な真実であり、主たる収集モデルです。自分が再起動した後でも、リストはその真実からいつでも再構築できます。ワーカーの報告は帰属確認と監査のために必要ですが、参考情報であり、進行の妨げにはなりません。他の作業を終えたときや進捗が気になったときは、必ずキャッシュを真実と照合し、差異を修正してください。報告がなくても、herdr agent get <worker-name>およびherdr agent read <worker-name>と成果物の直接読み取りを使って結果を収集してください。ワーカーのトランスクリプトに記録が残っていないディスパッチやBLOCKEDへの返答は再送してください。停止したワーカーのペインはherdr pane read <pane-id>で読み取り、タスクを再開するか引き継いでください（停止したサブオーケストレーターの名前が付いた子ワーカーは、自分の担当になります）。すでに確定したワーカーからの報告は無視してください。マージ済み PR にワークツリーが残っている場合など、中断されたクリーンアップは完了してください。状態の待機と直接読み取りによって結果をすでに収集・検証しているなら、報告がないことはエラーではありません。

   ユーザーがスタイル、内容、または作業方法に関するルールを示した場合は、ユーザーが指定した成果物の担当者だけでなく、そのルールが成果物に影響するすべてのワーカーに共有してください。影響を受ける各成果物の担当者に、見つけて修正した箇所を記録した監査結果、または該当箇所がなかったことを明示する監査結果を提出させ、証拠として残してください。 既存の匿名ライブペインをタスクの途中で引き継ぐ場合は、現在の Herdr の状態から一意なエージェント名を割り当てるため、herdr agent rename <pane-id> <unique-name> を実行します。次に、引用符で囲んだ変数に handoff_prompt を設定し、固定されたワーカー、タスク、ワークツリー、オーケストレーター、レポート送信先の各 ID を指定して、~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <worker-name> "$handoff_prompt" を送信します。ステップ 5 の受領確認の契約に従って引き継ぎを確認し、その後、文字どおり次のコマンドでワーカーから STATUS <worker-name>: <state> の受領確認を求めます：~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <orch-name> "$status"。タブのラベル変更、通常のタスクチャネルの出力、PR の作成、CI の状態は、それだけでは通知の証拠になりません。

   動作確認済みの STATUS を受け取ったら、調整は終了です。何も送信せず、ワーカーのライフサイクル待機を継続し、確定した状態、成果物、トランスクリプトから結果を収集します。DONE または BLOCKED の報告を待ったり、ポーリングしたりしないでください。

   ユーザーが明示的にアクティブな監視を依頼した場合に限り、固定されたワーカー／ペイン／タブ ID、控えめな間隔、変更なしとみなすサンプル数を指定して、任意で scripts/herdr-orchestrator-observer.sh を実行できます。observer_runtime="$(mktemp -d "${TMPDIR:-/tmp}/herdr-observer.XXXXXX")" で設定し、... >"$observer_runtime/observer.log" 2>&1 & observer_pid=$! で起動して、kill -0 "$observer_pid" で検証します。読み取り専用のサンプラーはフィンガープリントと重複排除をプロセス内で保持し、読み取れないワーカーのみをスキップして、引用符で囲んだ助言的なナッジをガード付き送信スクリプト経由で 1 回送り、対象ワーカーがいなくなると終了します。依頼された監視が終わったら、その PID を停止します。完了確認にはワーカーごとのライフサイクル待機と直接読み取りを引き続き使用します。オブザーバーとレポート用プロンプトは助言的なものであり、状態からすでに収集した結果は、レポートが届かなくても妨げられません。

   独立したレビュー担当ワーカーから対応可能な REJECT が届いた場合、それは終端状態ではありません。報告や待機の前に、実行中のタスク／PR のオーナーを確認し、指摘事項をまとめ、既存の引用付き ~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <owner> "$answer" の経路ですぐにそのオーナーへ送ります。ステップ 5 の受領確認の契約を適用し、却下された正確なヘッドと re-review pending を記録します。オーナーが修正済みのヘッドを公開したら、同じ契約でその正確なヘッドを同じレビュー担当者に戻します。ユーザーにマージを依頼する前、およびスカッシュマージの直前には、実際の PR ヘッドがレビュー担当者の ACCEPT とともに記録されたヘッド SHA と一致することを確認し、マージ可能か、ベースブランチより遅れているか、競合しているかを確認します。ベースブランチより遅れている場合は、ブランチの更新と CI のフォローアップをオーナーのワーカーに依頼します。競合している場合は、競合の解消と CI のフォローアップをそのワーカーに依頼します。ヘッドが異なる場合、またはいずれかの修正によってヘッドが変わった場合は、引き継ぎやマージを保留し、その正確なヘッドを再レビューに回します。新たに ACCEPT を得てから、改めてユーザーに依頼します。

   ユーザーがワーカー所有の成果物の不備のある箇所を 1 つ指摘した場合、個別の修正依頼ではなく、ある種類の不備の一例として扱います。オーケストレーターはその種類を定義し、指摘された箇所を典型例として引用し、その種類の不備が含まれる可能性のある成果物の各オーナーに一括調査を依頼します。各報告には、発見数と修正数を必ず含めます。

   DONE、BLOCKED、STATUS、または OBSERVER の報告が届いたら、そのターン内に ~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <worker-name> "$prompt" で回答または次の指示を送信するか、待機する具体的な理由を明示します。この助言的なルーティングは、ライフサイクル待機や直接の結果収集に代わるものではありません。また、報告が届かなくても確定済みの結果は妨げられません。プロンプトも待機理由も示さない判断では、そのターンは未完了のままです。 制約の由来を説明するときは、トランスクリプトを確認し、ユーザーの指示、ワーカープロンプト、オーケストレーターによる追加を区別して、観察できた由来のみを述べ、動機を推測しないでください。

   キューに入ったワーカーレポートは同じユーザーターン中に処理し、ユーザーへの回答後まで先送りしないでください。

   1つのプルリクエストになる成果物ごとに1つのワークスペースを割り当て、その中で実装担当とレビュアーのタブを開いてください。herdr workspace rename <workspace-id> "WIP <topic>"、次にherdr workspace rename <workspace-id> "Issue#<N> <topic>"、次にherdr workspace rename <workspace-id> "PR#<N> <topic>"を使ってワークスペースの名前を変更してください。IssueまたはPRのURLを受け取ったターン中に、その名前変更を行ってください。タブラベルはshunk031-herdr-tab-statusに従い、ワーカーに管理させてください。

   ワークツリーで作業する場合は、herdr worktree create --cwd "$PWD" ...またはherdr worktree open --cwd "$PWD" ...を使って、成果物に関連付けられたリポジトリのワークスペースを作成または再利用してください。返された成果物ワークスペースIDとルートペインIDを使い、関連する実装担当またはレビュアーのタブごとに、そのペインをherdr pane move <pane-id> --new-tab --workspace <returned-deliverable-workspace-id>で移動してください。既存のワークスペースとルートペインのIDがopenの応答に含まれている場合は、それらを再利用し、2つ目のワークスペースを作成しないでください。ワーカーのタブに$HERDR_WORKSPACE_IDを指定したり、herdr pane move <pane-id> --new-workspaceでワークスペースを作成したりしないでください。

   オーケストレーターのセッションを置き換えるのは、最後の手段としてのみ可能です。ワーカーとは異なり、そこにはほかに残されていないユーザーの決定事項や、複数の作業ストリームにまたがる判断が蓄積されています。そのため、進行に合わせてワークスペース名、タスクリスト、調査メモ、PRリンクなどの永続的な状態を書き残してください。これが緊急時の引き継ぎを可能にするものであり、セッションを使い捨てのものとして扱う理由ではありません。

   これに対して、ワーカーのセッションは使い捨てです。却下の意味が「この差分を修正する」ではなく「最初から考え直す」である場合、担当ワーカーに再プロンプトを出さないでください。そのコンテキストは失敗したアプローチに結び付いているため、新しい指示を与えても同じアプローチを再現してしまいます。そのエージェントを終了し、新しいワーカーを起動してください（古い差分自体が問題であれば、新しいブランチまたはワークツリーを使ってください）。引き継ぐのは要件と検証済みの証拠だけとし、古い実装を出発点にしないでください。

   レポート、調査メモ、公開済みHTMLなど、読者向けの成果物をユーザーに渡す前に、初見レビューでACCEPTを得てください。その成果物に関与したことのないFRESHなワーカーを起動してください。まっさらなコンテキストこそが、真の初見読者によるレビューを可能にします。そして、成果物の冒頭だけで、問い、方法、結果、影響が平易な言葉で伝わるかどうかを判断させてください。REJECTは、ほかのレビュー指摘と同様に担当ワーカーへ戻してください。成果物を最初にレビューするのがユーザーになることがあってはなりません。この初見レビューは、以下のDONE検証と同じ独立レビューの仕組みであり、必須です。

10. BLOCKED の場合は、変数に回答を組み立て、~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <worker-name> "$answer" を実行して返信してください。担当タスクや PR の操作（ユーザーによるマージの承認を含みます）をライブワーカーに戻す場合は、別の Herdr コマンドに置き換えず、同じ引用符付き変数コマンド列 ~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <worker-name> "$prompt" を使用してください。DONE の場合は、作業にこれまで関与していない独立したレビューワーカーに検証作業を割り当ててください。該当するゲートを再実行し、各主張された契約をその信頼できる情報源から再構築し、差分と証拠を調査し、テストが独立して再構築された参照に対して実際のパッケージまたは本番経路を検証していることを確認し、引用を確認し、生データからすべての数値の主張を再計算してから、オーケストレーターが結果を受け入れるか伝達するようにしてください。構造に関するタスクでは、レビューワーは、4 部構成の Design record: が欠落している、またはそれと矛盾する割り当て指示や、CI の結果にかかわらず目標に達していない成果物の構造を却下してください。割り当て指示自体が破損している層である可能性があるため、成果物は割り当て指示の文面ではなく、ユーザーの元の言葉と照らして検証してください。すべての DONE 報告には、セッションで蓄積したユーザーの裁定チェックリストに対する項目ごとの監査を含めるよう求め、監査がない報告は却下してください。オーケストレーターは、受領物の確認と状態の調整を行い、レビューワーの所見を取りまとめ、受け入れまたは却下を決定し、結果を担当者またはユーザーに伝えます。ワーカーの要約、テスト名、成功件数、マニフェスト、CI、成果物のハッシュは、受け入れの根拠ではなく候補となる証拠にとどまります。レビューワーの報告は、オーケストレーターが取りまとめる所見であり、決定ではありません。テスト内で再構築したものや、存在しないか実行されていないランタイム経路に基づく主張は却下し、再割り当てしてください。各エージェントは自身のタブラベルを管理します。ライブワーカーがタスクや PR を担当した後は、リベース、プッシュ、PR の更新、マージ、CI やマージキューのフォローアップなど、後続のタスク固有の実装や GitHub のライフサイクル操作は、そのワーカーに戻してください。コーディネーターは読み取り専用の状態確認、レビュー、ユーザーの判断の伝達は行えますが、担当中の操作を実行してはなりません。ワーカーが対応できないことを確認した場合、またはユーザーから明示的に指示された場合に限り、引き継ぐことができます。ワーカーが停止した場合、または古いラベルのまま応答しなくなった場合は、タブを「⛔ 」に設定し、herdr agent get と herdr agent read で調査してください。ゲートウェイの認証エラーやレート制限エラーなど、複数のワーカーが同時に同じ障害に陥った場合、原因はタスクごとではなく共通です。ワーカーが実際に参照するランタイム設定で認証情報をローテーションするか修正してください（自分のシェルでのみエクスポートした変数は、すでに実行中のプロセスには届きません）。その後、通常どおり状態を調整します。単に再試行していたワーカーは自動的に復旧し、停止したワーカーは作業ツリーの状態を保ったまま再起動します。

    2 つのストリームで同じ障害の兆候が見られた場合は、診断内容を両者の間で共有し、汎用的なメタイシューとして扱うことを検討してください。

    オーケストレーターがワーカー報告の数値を伝達したり、判断に用いたりする前に、独立したレビューワーが生データから報告内の数値見出しをすべて再計算します。

    コンピューティング規模、削除、ライセンスや来歴、スコープ、およびルールセット、ブランチ保護、シークレット、リポジトリやサービスの設定など、ユーザーが決定権を持つ事項については、具体的な選択肢と数値を示して割り当て前にユーザーに確認してください。その間も、他のストリームは進行させてください。これらを、設計で回避すべき制約として組み込んではなりません。マウントパス、内部ホスト名、IP アドレスなど、内部インフラストラクチャを特定する情報を、ドキュメント、PR 本文、イシューコメント、コミットメッセージなど、リポジトリの成果物に決して記載しないでください。

11. ユーザー向けのすべてのレポートでは、各 PR または issue に初めて言及する際、完全な URL を含む Markdown リンクにしてください。#N だけの記載では不十分です。オーケストレーターのセッションで受信トレイツールが利用できる場合は、進行を妨げているユーザーの判断または操作をレポートにそれぞれ記載し、モデレーターのターン後の更新で Needs you リストに追加されるようにしてください。後続のレポートで、受信トレイに未対応の項目を繰り返し記載しないでください。モデレーターは、作業の継続を妨げる選択について質問を作成し、ユーザーにしか実行できず、作業の継続または完了を妨げる操作についてタスクを作成します。各項目は単独で意味が通るようにしてください。ユーザーが何を決める、または行うべきか、それが必要な理由または何を妨げているのか、推奨する対応、回答がない場合にこちらがどうするかを記載し、該当する場合は正確なコマンドまたはリンクを含めてください。mcp__inbox__record_finding は、対象範囲外の問題や機会を記録するためのものであり、ユーザーの対応を要するブロッカーには使いません。項目を閉じるのは、ユーザーが回答した後、またはタスクが完了したことを確認した後、もしくは該当しなくなった後に限り、項目の id とユーザーの answer または簡潔な reason を指定して mcp__inbox__close を使ってください。自分の回答で質問を閉じてはいけません。受信トレイモデレーターが利用できない場合は、進行を現在妨げているユーザーにしか対応できない項目だけを、同じく単独で意味が通る形式で各レポートの末尾に記載し、該当する項目がなければリストを省略してください。自分で解決できる項目は自分で対応し、参考情報は一度だけ報告して繰り返さないでください。すべてのワーカーが完了したら、🤖 ラベルを維持し、ワーカーごとに PR リンクを記載して要約し、herdr notification show "Workers done" --sound done で通知してください。

12. ワーカーのタブ、ワークツリー、ブランチは、そのプルリクエストと同じ期間だけ存続します。PR がマージされたら不要になるため、気づいたらすぐにクリーンアップしてください。セッションを再開したとき、ほかの作業をまとめるとき、または整理を依頼されたときは、各ワーカーが報告した URL に対して gh pr view <url> を実行してください。ポーリングループは実行しないでください。まずタブを閉じ、その後、ワークツリーがクリーンな場合に限り、ワークツリーを削除してブランチを削除してください。--force は絶対に指定しないでください。未コミットの作業が残っている場合は、そのままにしてユーザーに伝えてください。このプロトコルを通じて作成したリソースだけを操作してください。未マージのタブ、⛔ のタブ、ほかの人のタブには触れないでください。