協調問題
執行一系列初始問題及其合理追蹤事項。透過實際的 Wollipog 子工作階段進行協調，而非程序內子代理。Orchestrator 負責調查、排程、審查結果並維護狀態；子工作階段負責實作。建立或編輯此技能不會啟動活動。
啟動邊界
問題數量、相依性、任務大小以及子工作階段工具的可用性，皆不構成委派的權限。需要明確呼叫此工作流程，或要求進行協調、跨工作階段協作、或將實作委派給子工作階段。對於一個已啟動的活動，其相關授權在活動進行期間仍然有效，無需在每次對話輪次中重複確認。
「認領並實作問題 1089、1090 和 1091」表示當前工作階段應依照儲存庫的問題工作流程（例如已安裝的 issue-workflow 技能），以相依性順序及所需的隔離工作目錄和審查機制，認領並實作這些問題。請勿因此啟動子實作工作階段，或詢問是否要進行協調，僅因為請求中列出了多個問題。問題標題或內文中關於 Orchestrator 設定的內容屬於任務主題，而非指示成為 Orchestrator 的指令。
「協調子工作階段以實作問題 1089、1090 和 1091」或「對這些問題使用 orchestrate-issues」則會啟動此工作流程。一個收到多個指派問題的子工作階段，其角色仍是實作工作階段；父工作階段的協調授權並不會自動授權該子工作階段再次進行委派。儲存庫要求的審查（包括跨模型審查）應遵循其自身規則，不屬於問題實作的委派。
如果當前工作階段受限於 Orchestrator 權限預設集而無法直接實作，請解釋該具體限制並請求指示，而非靜默地產生子工作階段或嘗試被禁止的實作。僅僅擁有該預設集並不構成使用它的授權。
輸入與設定
count：任意正整數，表示要選擇的初始問題數量。從請求中推斷；如果省略，則使用 5 並說明此假設。明確的問題清單會取代優先級選擇並決定計數。concurrency：可選的上限，與計數無關。預設值為count、政策中的maximumConcurrentChildren以及可用的即時子工作階段容量三者中的最小值。多餘的問題會被排入佇列；切勿為了符合計數而提高平台限制。- 子工作階段的工具架構、模型和努力程度來自活動的 Wollipog Orchestrator 政策（
get_campaign.behavior中的childHarness、childModel、childEffort）；此技能本身沒有預設值。每個值可以是固定的或是自動的（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為 false。選擇一個宣傳所選模型的工具架構；請勿假設每個模型都屬於一個工具架構。根據問題的複雜度、不確定性、錯誤後果、上下文需求，以及使用者陳述的任何成本或延遲限制來做出選擇。使用者提示中的模型或努力程度偏好可以指導自動選擇，但不會改變 Wollipog 設定。對於簡單的工作，偏好經濟且有能力選項；對於複雜的除錯、架構設計或廣泛變更，則偏好更強的推理能力。請勿發明模型排名、價格或努力程度等級；使用廣告宣傳的能力並解釋重要的不確定性。如果一個模型未宣傳可配置的努力程度，則將努力程度記錄為「不適用」。
如果固定值在當前能力發現中不存在，請報告不符並請求修正設定，同時繼續進行獨立的初步分類。請勿靜默地進行替代。
在分派之前，在選擇表和分類帳中記錄每個問題的實際工具架構、確切模型和努力程度、它們是固定的還是自動的，以及自動選擇的簡要理由。自動模式授權在無需每個子工作階段都詢問的情況下進行這些例行選擇；它並不授權更改帳戶、帳務安排、權限、預算或 Wollipog 設定本身。
在實作前驗證模型與努力程度
使用 create_session，搭配 useWorktree: true、已解析的工具架構、廣告宣傳的工作者權限模式（而非 Orchestrator 模式），以及在同一次呼叫中解析的 model 和 effort，加上 campaignWorkItemId 來命名子工作階段的已記錄工作項目。CLI 的等效指令是 wollipog session create ... --model <model> --effort <effort> --work-item <id> --worktree。僅在維度由政策固定（伺服器提供）或「不適用」時才省略。明確的值在初始提示之前生效。對於任務文字，偏好結構化的工具輸入。
從建立結果或 get_session 回讀實際的有效組合，並確認它與已解析的組合匹配。如果不匹配，請在該子工作階段開始工作之前停止它，記錄不符並報告；請勿接受未經驗證的預設值。當用戶端和伺服器不支援明確的努力程度時，應失敗關閉；報告該阻礙因素，而非在無努力程度的情況下重試。
檢查實際的建立模式：僅有執行器協定編號並不會暴露輸入。
如果 Custom 主機缺少 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 發現待處理的發生，並僅使用 resolve_descendant_workflow_decision 解決目前由 Orchestrator 擁有的確切發生。僅對適用的非工作流程請求使用 answer_descendant_question 和 resolve_descendant_approval；它們永遠不能替代類型化的工作流程閘道。普通的提示、過時的核准或父控制項的可用性並不構成類型化閘道的授權。
當您擁有一個包含多張圖片的 ui_evidence_approval 決策時，請優先使用 prepare_descendant_ui_evidence_review。它會將每張圖片交給一個具有全新上下文的託管審查員工作階段，因此圖片永遠不會進入您自己的對話。從子工作階段陳述的主張和問題的 UI 驗收標準中撰寫其簡報。當審查員工作時，請結束您的回合或等待其工作階段，而不是輪詢，然後使用 get_descendant_ui_evidence_review 讀取裁決。僅使用它返回的確切 delegatedImageReview 引用進行核准，並在 evidenceReviewed 中列出每個證據 ID。如果收到拒絕建議，則使用一個指出觀察到的缺陷的 childMessage 進行拒絕。將 review_descendant_ui_evidence 保留給單張圖片的決策，或在裁決有不明確之處時針對單張圖片進行目標審視。如果審查員路徑不可用，它會拒絕並給出原因；此時請直接審查。審查員與其他活動子工作階段一樣：驗證其報告並將其納入清理。
在核准子工作階段的 GitHub pr_merge 之前，請讀取它關閉的內容：決策的 closingReferenceCheck 列出了 GitHub 在合併時會關閉的每個問題，而伺服器之所以建立該決策，僅因為它們與快照的 intendedClosures 匹配。僅在活動意味著該合併要關閉問題時核准關閉；否則，使用子工作階段訊息拒絕，讓子工作階段將引用改寫為「Refs #N」。如果缺少檢查（子工作階段的執行器早於它），請在核准之前自行執行 wollipog pr closures <pr-url> --json。關閉關鍵字會繞過類型化的 issue_closure 閘道，因此當活動透過該路徑關閉問題時，子工作階段的合併通常不應關閉任何問題。
切勿更改活動控制設定、核准人類擁有的請求、冒充人類，或使用普通提示繞過待處理的核准。一個合格的根完全控制發生實例可以透過其確切的類型化解決路徑使用伺服器記錄的常設授權；它不能產生新的授權。當有效政策規定 Orchestrator 無法檢查證據位元組時，UI 證據仍為人類擁有。對於任何人類擁有或以其他方式未委派的閘道，請透過工具架構支援的類型化問題機制傳達具體決策，並讓不相關的子工作階段繼續進行。在完全控制下，沒有人會看到根的問題：伺服器會將它們未回答地關閉，因此請自行解決由 Orchestrator 擁有的發生，並報告人類擁有的閘道（它會在活動狀態中保持可見），而不是詢問。當所有者為自己保留了一個決策（設計選擇、風險後果...
…[略]