picoduck/orchestrate-issues

イシュー調整（Orchestrate Issues）

初期イシューとその正当なフォローアップのキャンペーンを実行します。プロセス内サブエージェントではなく、実際のWollipog子セッションを通じて調整します。Orchestratorは調査、スケジュール設定、結果の確認、状態維持を行い、子セッションが実装を担当します。このスキルの作成や編集はキャンペーンを開始しません。

起動条件

イシュー数、依存関係、タスクサイズ、子セッションツールの利用可能性は、委任を許可しません。このワークフローの明示的な呼び出し、またはセッション間での調整、子セッションへの実装委任の依頼が必要です。アクティブなキャンペーンに対してすでに確立された関連する承認は有効であり、ターンごとに繰り返す必要はありません。

「イシュー1089、1090、1091を主張して実装する」は、現在のセッションがそれらのイシューを主張し、リポジトリのイシューワークフロー（インストールされた issue-workflow スキルなど）に従い、依存関係順に、必要な隔離ワークツリーとレビューを伴って実装することを意味します。子実装セッションを起動したり、単にリクエストに複数のイシューがリストされているという理由だけで調整を尋ねたりしないでください。Orchestrator設定に関するイシュータイトルや本文はタスクの主題であり、Orchestratorになるための指示ではありません。

「子セッションを調整してイシュー1089、1090、1091を実装する」または「それらのイシューにorchestrate-issuesを使用する」は、このワークフローを起動します。複数の割り当てられたイシューを受け取った子セッションは、依然として実装セッションです。親の調整承認は、その子が再委任することを自動的に許可しません。リポジトリが必要とするレビュー（クロスモデルレビューを含む）は、それ自体のルールに従い、イシュー実装の委任ではありません。

現在のセッションがOrchestrator権限プリセットによって制限されており、直接実装できない場合は、具体的な制限を説明し、黙って子セッションを生成したり、禁止された実装を試みたりするのではなく、指示を仰いでください。プリセットが利用可能であるだけでは、それを使用する権限にはなりません。

入力とセットアップ

• count: 任意の正の整数。選択する初期イシューの数。リクエストから推測します。省略された場合は5を使用し、その前提を述べます。明示的なイシューリストは優先順位選択を置き換え、カウントを決定します。
• concurrency: オプションの上限。countとは独立しています。デフォルトは、count、ポリシーのmaximumConcurrentChildren、利用可能なライブ子セッション容量のうち最小のもの。超過したイシューはキューに入れます。プラットフォームの制限をカウントに合わせて引き上げることは決してしないでください。
• 子ハーネス、モデル、努力レベルは、キャンペーンのWollipog Orchestratorポリシー（childHarness、childModel、childEffort in get_campaign.behavior）から取得します。このスキルには独自のデフォルトはありません。各値は固定値または自動（null）のいずれかです。子モデルと努力レベルの解決を参照してください。
• レビューアは、リポジトリのレビューワークフローで指定されたモデルを保持します。
• ユーザー指定のオプションのコスト、時間、総イシュー数、またはフォローアップ深度の制限。継承されたガードレールを保持します。予算値や任意の成功した停止ラウンドを発明しないでください。

using-wollipog、リポジトリの説明書、およびリポジトリまたはユーザーが提供するイシューワークフロー、レビュー、イシューレポートスキルまたはポリシーを読んでください。using-wollipogのみが必要です。リポジトリがイシューワークフローを定義していない場合、子セッションはそのコントリビューションガイドラインとこのスキルのゲートに従います。子セッションは、その実行環境で同じスキルを利用可能でなければなりません。その環境のカタログからスキルパスを解決します。このマシンのホームパスが他の場所に存在するとは想定しないでください。公開ペイロードを準備する前に、リポジトリのイシューレポートポリシーを読んでください。

現在のランナー、リポジトリ/ワークスペース、利用可能なワーカーハーネスとモデル/努力レベルの能力、子セッション容量、サポートされているセッションツールを発見します。選択したモデルを宣伝するハーネスを選択します。すべてのモデルがCodexに属するとは想定しないでください。何かを作成する前に、現在のセッションとライブ子セッションリストを検査します。許可されたOrchestrator操作のみを使用します。プロジェクトへの書き込みと実装は子セッションに属します。キャンペーン台帳は、永続的なセッションアーティファクトまたは許可されたスクラッチに保持し、プライマリチェックアウトには決して保持しません。譲歩またはコンパクションの前に、その最新の状態を会話に要約します。

子モデルと努力レベルの解決

何かを選択する前に get_campaign.behavior から childHarness、childModel、childEffort を読み取り、各ディスパッチの前に再度読み取ります。人がキャンペーンの実行中にそれらを変更する可能性があり、その後作成された子セッションのみが新しい値を使用します。WollipogのOrchestrator設定がこれらの値の唯一のソースです。このスキルに書かれたモデルや努力レベル、以前のキャンペーンから記憶されたもの、または親セッションから継承されたものにフォールバックしないでください。

• 固定値: 正確に使用します。サーバーは create_session がそれを省略した場合に固定値を入力し、異なる値を拒否するため、上書きしないでください。ユーザーのプロンプトが固定設定とは異なるモデルや努力レベルを要求した場合は、競合を報告し、ユーザーにWollipog設定の変更を依頼します。解決されるまで影響を受けるイシューをディスパッチしないでください。
• 固定ハーネス: 固定された childHarness はハーネスを指定し、各マシンにはそれ用の独自のエージェントがあります。get_campaign が childHarnessAgents を返す場合、子セッションを作成するマシンにリストされている agentId を渡します。null とリストされているマシンはそれを実行できません。エージェントを childHarness.agentId から導出しないでください。それはどのマシンのエージェントである必要もありません。
• 固定モデルまたは努力レベル: get_campaign が childModelMachines を返す場合、supported とマークされたマシン上でのみ子セッションを作成します。他のマシンはそのモデルと努力レベルを実行できず、そこでの作成は拒否されます。
• 自動（null）: 各割り当てに対して、get_agent_capabilities（MCP）または wollipog session capabilities（CLI）から選択します。page.nextOffset が truncated でなくなるまで従います。選択したモデルを宣伝するハーネスを選択します。すべてのモデルが1つのハーネスに属するとは想定しないでください。イシューの複雑さ、不確実性、ミスの結果、コンテキストニーズ、およびユーザーが述べたコストやレイテンシの制約に基づいて選択します。ユーザーのプロンプトにおけるモデルや努力レベルの好みは自動選択を導きますが、Wollipog設定は変更しません。単純な作業には経済的で能力のあるオプションを、複雑なデバッグ、アーキテクチャ、または広範な変更にはより強力な推論を優先します。モデルのランキング、価格、努力レベルを発明しないでください。宣伝された機能を使用し、重要な不確実性を説明します。モデルが設定可能な努力レベルを宣伝しない場合、努力レベルを「該当なし」と記録します。

固定値が現在の能力発見に存在しない場合は、不一致を報告し、独立したトリアージを続けながら修正された設定を要求します。黙って代用しないでください。

各イシューのハーネス、正確なモデルと努力レベル、それぞれが固定か自動か、および自動選択の簡単な理由を、ディスパッチ前に選択テーブルと台帳に記録します。自動モードは、子セッションごとに尋ねることなくこれらのルーチン選択を承認します。アカウント、課金設定、権限、予算、またはWollipog設定自体の変更は承認しません。

実装前にモデルと努力レベルを確認

create_session を useWorktree: true、解決されたハーネス、宣伝されたワーカー権限モード（Orchestratorモードではない）、解決された model と effort を同じ呼び出しで、さらに子セッションの記録されたワークアイテムに名前を付ける campaignWorkItemId と共に使用します。CLIの同等のものは wollipog session create ... --model <model> --effort <effort> --work-item <id> --worktree です。ポリシーによって固定されている（サーバーが供給する）か「該当なし」の場合のみ、次元を省略します。明示的な値は初期プロンプトの前に適用されます。タスクテキストには構造化されたツール入力を優先します。

作成結果または get_session から有効なペアを読み取り、解決された組み合わせと一致することを確認します。一致しない場合は、その子セッションが作業を行う前に停止し、不一致を記録して報告します。未確認のデフォルトを受け入れないでください。明示的な努力レベルをサポートしないクライアントとサーバーは、フェイルクローズします。そのブロッカーを報告し、努力レベルなしで再試行しないでください。

実際の作成スキーマを検査します。ランナープロトコル番号だけでは入力は公開されません。 カスタムホストに campaignWorkItemId がない場合は、作成時に読み取り専用のブートストラップ割り当てのみを使用し、 有効な設定を確認し、サポートされている割り当てツールで元のワークアイテム割り当てを記録し、 実装を解放する前に専用のワークツリーを選択します。そのホストでのアトミックなワークアイテムバインディングを主張したり、 必要な保護された入場をバイパスしたりしないでください。それらの操作が利用できない場合は、互換性ブロッカーを報告します。 キャンペーンをホストしているスタックを決して更新しないでください。

子セッションを再利用する前に設定を再確認します。自動割り当ての場合、証拠が以前の選択が不十分であったことを示し、その理由を記録した場合、組み合わせを再検討します。アイドル中にサポートされている設定操作を通じてのみ変更を適用し、解放前に確認するか、明確な所有権の引き継ぎを伴う代替を作成します。通常の prompt_session メッセージはセッション設定を変更しません。ポリシーで固定された値を変更しないでください。

権限とゲート

using-wollipog に同梱されている「キャンペーン権限プレフライト」リファレンスを読んでください。ディスパッチ前に、 有効なカスタム/フルコントロールモード、人間が確立した境界とリビジョン、許可された操作、 現在の所有者、互換性、証拠の宛先/プロバイダーの開示、および人間必須の例外を記録します。 未解決の必須人間ルールを正確な指示ソースによって特定します。外部またはユーザー作成の指示を決して黙って書き換えないでください。 フルコントロールは、リポジトリポリシーによって許可された、サーバーが確立した権限にのみ適用されます。 カスタムは既存の承認要件を保持します。変更されたポリシーは、それ自体の明示的に承認されたコントリビューションワークフローを通過する必要があります。

ユーザーの実際のキャンペーン承認とリポジトリルールを引き継ぎます。ルーチンの主張、隔離ワークツリー、テスト、プッシュ、PRのオープン、および必要なレビューは、繰り返しの許可を必要としません。既存のルールは、PRマージごとの承認、UIエビデンスレビュー、リモートブランチ削除の承認、および各正確にサニタイズされたイシューペイロードの承認を依然として必要とする場合があります。このワークフローのリクエストを、それらのゲートの放棄に黙って変換しないでください。

ディスパッチ前、およびワークフロー決定を解決する前に、get_campaign を使用して信頼できる現在のキャンペーン状態とサーバー派生ポリシーを読み取ります。サーバー状態が利用可能な場合、プロンプトコピーに依存しないでください。implementation_question、pr_merge、merged_branch_deletion、follow_up_issue_publication、ui_evidence_approval、review_round_extension などの型付き決定の場合、子セッションは、対応するアクションの直前の正確な発生に対して request_workflow_decision、get_workflow_decision、consume_workflow_decision を使用する必要があります。親は子に代わってゲートを作成したり消費したりしてはなりません。list_descendant_requests で保留中の発生を発見し、現在Orchestratorが所有する正確な発生のみを resolve_descendant_workflow_decision で解決します。answer_descendant_question と resolve_descendant_approval は該当する非ワークフローリクエストにのみ使用します。それらは型付きワークフローゲートの代わりにはなりません。通常のプロンプト、古い承認、または親コントロールの利用可能性は、型付きゲートの承認ではありません。

複数の画像を含む ui_evidence_approval 決定を所有している場合は、prepare_descendant_ui_evidence_review を優先します。すべての画像を管理レビューアセッション（新しいコンテキスト）に渡すため、画像が自身の会話に入ることはありません。子セッションの主張とイシューのUI受け入れ基準から簡単な説明を記述します。レビューアが作業している間、ポーリングする代わりにターンを終了するか、そのセッションを待機し、その後 get_descendant_ui_evidence_review で評決を読み取ります。承認は、それが返す正確な delegatedImageReview 参照でのみ行い、evidenceReviewed にすべてのエビデンスIDをリストします。拒否勧告の場合は、観察された欠陥を指定する childMessage とともに拒否します。1つの画像に対する決定、または評決が不明瞭な場合の1つの画像への対象を絞った確認には、review_descendant_ui_evidence を保持します。レビューアパスが利用できない場合は、理由とともに拒否されるため、代わりに直接レビューします。レビューアは他の子セッションと同様のキャンペーン子です。そのレポートを確認し、クリーンアップに含めてください。

子セッションのGitHub pr_merge を承認する前に、それがクローズするものを読み取ります。決定の closingReferenceCheck は、マージ時にGitHubがクローズするすべてのイシューをリストし、サーバーはそれらがスナップショットの intendedClosures と一致する場合にのみ決定を作成しました。キャンペーンがそのマージでイシューをクローズすることを意味する場合にのみクロージャを承認します。それ以外の場合は、子セッションにメッセージを添えて拒否し、子セッションが参照を「Refs #N」と言い換えるようにします。チェックがない場合（子セッションのランナーがそれより前の場合）、承認する前に自分で wollipog pr closures <pr-url> --json を実行します。クロージングキーワードは型付き issue_closure ゲートをバイパスするため、キャンペーンがそのルートを通じてイシューをクローズする場合、子セッションのマージは通常何もクローズしないべきです。

キャンペーン制御設定を変更したり、人間が所有するリクエストを承認したり、人間を偽装したり、保留中の承認をプレーンプロンプトでバイパスしたりしないでください。適格なルートフルコントロールの発生は、その正確な型付き解決ルートを通じてサーバー記録の恒久的承認を使用できますが、新しい許可を発行することはできません。アクティブなポリシーがOrchestratorがエビデンスバイトを検査できないと言っている場合、UIエビデンスは人間が所有したままです。人間が所有する、またはその他の方法で委任されていないゲートについては、ハーネスのサポートされている型付き質問メカニズムを通じて具体的な決定を中継し、関連のない子セッションを進行させ続けます。フルコントロール下では、誰もルートの質問を表示しません。サーバーはそれらを未回答として破棄するため、Orchestratorが所有する発生を自分で解決し、代わりにキャンペーンステータスに表示され続ける人間が所有するゲートを報告します。尋ねる代わりに。所有者が自分自身のために決定を保持した場合（設計上の選択、リスクの考慮...

[翻訳のため省略]