paseo-committee

委員會 Skill (Committee Skill)

由來自不同模型供應商（provider）的兩名 Agent 組成，在全新的上下文（context）中平行規劃解法。實作完成後，兩位 Agent 仍會保持存活以進行後續審查。

本委員會的核心目的是跳脫現有思維，而不是在原本的死胡同裡越陷越深。委員會可能會提出截然不同的處理方式。

使用者的額外上下文： $ARGUMENTS

前置條件

請先閱讀 paseo skill。除非使用者在本次請求中已明確指定供應商，否則在挑選委員會成員前，必須先讀取 ~/.paseo/orchestration-preferences.json。在讀取該檔案之前，切勿建立委員會 Agent。

委員會的關鍵價值在於「異質性與對比」，因此請依據設定的偏好，刻意跨不同供應商挑選成員，而非直接套用寫死的預設值。

成員組成

由編排偏好設定（orchestration preferences）中選出兩名具備不同推理風格的成員：

• 一家擅長規劃／研究的模型供應商
• 一家具備強大推理能力且風格迥異的模型供應商

僅在使用者明確要求替換成員時，才覆寫此規則。

鐵律

• 禁止修改（No edits）。 傳送給委員會成員的每一條 prompt 結尾，都必須附上禁止修改的後綴：

  This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code.
  

• 信任等待過程。 請勿頻繁輪詢（poll）、發送催促訊息或中斷。GPT-5.4 的推理過程可能長達 15 至 30 分鐘；Opus 亦會進行深度思考。等待時間長，代表模型發現了值得深入挖掘的問題。

• 你是中間協調者。 主導「規劃 → 實作 → 審查」的完整流程，無須將主導權移交給使用者；除非遇到需要由使用者裁決的重大分歧。

第一階段：規劃

撰寫一份針對問題層面的 prompt：

• 高階目標與驗收標準
• 限制條件
• 異常症狀（若為 Bug）
• 過去嘗試過的方法以及失敗原因
• 明確要求：「進行根因分析（do root cause analysis）」
• 明確要求：「說明前提假設，至少進行三層深度的追問，並確認你是在治標（修補症狀）還是治本（根除問題）」

透過 Paseo 同時建立兩名 Agent，標題設為 [Committee] <task> 並帶入相同的 prompt。請耐心地等待「兩者皆完成」，而非只看先完成的那一個。

仔細閱讀雙方的回覆，並對內容提出質疑，切勿照單全收：

• 「為什麼 <底層機制/現象> 會發生？這是表面症狀還是根本原因？」
• 驗證方案中針對程式碼所作的任何假設。
• 「你曾考量過哪些方案？最後為何放棄它們？」

持續發送追問與跟進訊息，直到方案真正觸及並解決根本原因。

綜合整理：

• 達成共識 → 彙整為統一方案。
• 出現重大分歧 → 請使用者參與裁決。

向兩位成員確認合併後的方案。進行多輪對話直至達成最終共識。

第二階段：實作

預設情況：由你親自實作。若使用者明確表示 "delegate"（委派），則啟動一名實作 Agent 並將整合後的方案交付給它。

委員會保持獨立與客觀，不參與具體的程式碼實作。

第三階段：審查

將變更的 diff 傳送給委員會：

Implementation is done. Review changes against the plan. Flag drift or missing pieces. <no-edits suffix>

由你親自修正意見，或將反饋發送給實作 Agent。重複「第二階段 → 第三階段」，直到達成共識。

若迭代約 10 次後仍無法達成共識，請附上過往所有嘗試的完整歷史紀錄，重新組建一個全新的委員會——因為當前委員會的上下文可能已經產生了嚴重偏離。