詰問 (Interrogate)
為每個設定的模型生成一個審查者，以對抗性方式審查程式碼變更。每個模型獲得相同的提示和評分標準。對抗性訊號來自模型的多樣性，而非指派的角色。
一個發現只有在運行證明它時才算數。
最終產出是一個綜合判斷。請勿自動套用變更。
步驟 1，界定範圍
從上下文確定要審查的內容：
- 如果使用者指向特定檔案或差異，則使用該內容
- 如果是在功能分支上，則執行
git diff main...HEAD（或適當的基底分支）以獲取完整的變更集 - 如果使用者的訊息提及最近的工作，則收集相關檔案
將差異（或檔案內容）以及審查者理解程式碼所需的任何相關上下文檔案打包在一起。
步驟 2，陳述意圖
在生成審查者之前，明確陳述意圖。從以下內容推導：
- 使用者的訊息
- 提交訊息
- PR 描述（如果存在的話）
- 程式碼本身
撰寫一個清晰的段落。如果不確定意圖，請先詢問使用者再繼續。
步驟 3，生成審查者
在一則訊息中啟動所有審查者，每個槽位一個，使用工具組的子代理工具或 delegate_task。
目標是模型多樣性：不同的模型系列能發現不同的錯誤。在 T3 Code 中，從使用者的最愛中挑選 3-4 個來自不同系列的強大模型，並使用 delegate_task 啟動每個模型（t3-tools 技能包含相關步驟）。在其他地方，選擇工具組提供的 3-4 個不同的高能力模型。如果無法為每個子代理選擇模型，則在不覆蓋模型的情況下啟動審查者，並透過獨立的上下文來獲得多樣性。
| 子代理 | 角色 |
|---|---|
| 審查者 A | 推理密集型審查者 |
| 審查者 B | 第二個，獨立的模型系列 |
| 審查者 C | 第三個，快速/不同的系列 |
| 審查者 D | 對抗性/嚴格的程式碼品質審查者 |
對於每個審查者，啟動一個通用目的子代理：
- OpenCode / Codex：
subagent_type: general（透過task工具） - Claude Code：
subagent_type: general-purpose - 其他工具組：最接近的通用子代理，且能夠讀取儲存庫
讓審查者在精神上保持唯讀：他們不得編輯檔案。需要重現問題的審查者應在其自己的暫存副本或工作樹中執行，絕不直接在原地執行。
為每個審查者提供此簡報以及已填寫的範本：
打破這個變更。透過針對真實程式碼的運行來證明每個發現，例如失敗的測試、重現腳本，或顯示錯誤行為的命令輸出。對於設計或計劃，請執行原型或探查當前樹。將重現步驟保留在自己的工作樹中。報告每個發現時，請附上標題、確切命令、命令輸出的內容，以及意圖要求的輸出。省略任何你未執行的內容。這涵蓋了風格、命名、結構，以及需要未來變更才能解決的風險。沒有任何發現也是一個有效的結果。
如果某個模型標籤被拒絕為無法解析，請檢查 Task 工具錯誤訊息中的有效標籤，選擇最接近的等價物（偏好同一系列中最高推理層級的模型），並使用有效的標籤啟動。不要因為標籤問題而阻塞審查。
閱讀 references/reviewer-prompt.md 並使用以下內容填寫範本：
- 已陳述的意圖
- 差異或檔案內容
references/rubric.md中的審查評分標準references/code-quality-review.md中的程式碼品質透鏡
相同的已填寫範本將提供給所有審查者，以便每個模型都應用程式碼品質透鏡。
步驟 4，綜合
當結果返回時，建立一個統一的圖景：
- 驗證每個發現：重新執行其命令。當輸出顯示失敗且該失敗違背意圖時，保留該發現。丟棄其餘的。合併具有相同根本原因的發現。
- 解析來自審查者的所有發現
- 識別共識。由 2 個以上模型獨立提出的發現具有最高信號強度。
- 識別單一模型發現。仍然值得閱讀，但需相應加權。
- 去重。不同模型可能以不同方式描述相同問題。合併這些發現，並註明哪些模型提出了它。
- 記錄分歧。如果一個模型標記了某件事，而另一個模型明確表示相反意見，這對於判斷來說是有用的背景資訊。
步驟 5，主導判斷
你是主導審查者，一位務實的資深工程師，而不是中立的彙總者。
閱讀 references/lead-judgment.md 以獲取完整框架。
使用以下類別對每個發現進行分類：
- 立即行動 (Act on)。影響正確性、安全性或可維護性的真實問題，考量到實際目標。這些會阻止一個真實的 PR。
- 考慮 (Consider)。合理的觀點，但你不確定它們目前是否值得花費成本來解決。值得使用者關注。
- 註記 (Noted)。技術上有效但不可操作。依賴上下文、過早最佳化，或在當前階段影響較低。
- 駁回 (Dismissed)。錯誤、吹毛求疵，或缺乏上下文。簡短說明原因。
對於每個發現，請包含：
- 提出該發現的模型
- 分類（立即行動 / 考慮 / 註記 / 駁回）
- 分類原因的一行說明
輸出格式
以以下結構呈現判斷結果：
意圖
[步驟 2 中陳述的意圖段落]
審查者
- 審查者 [標籤]: [模型名稱]，[N 個發現]（每位審查者一個項目符號）
立即行動
[應處理的發現。對於每個發現：描述、哪些模型提出、為何重要。]
考慮
[值得思考的發現。對於每個發現：描述、哪些模型提出、涉及的權衡。]
註記
[有效但優先級低。簡短列表。]
駁回
[被拒絕的發現，附簡短理由，包括未被運行證明的發現。]
一致性地圖
[模型在哪裡達成一致，在哪裡出現分歧，以及這種一致/分歧的模式告訴我們什麼？]
爆炸半徑 (Blast radius)
當變更很小但尚未被信任，且問題在於它會破壞差異之外的哪些內容時，使用此模式。列出呼叫者並非其工作。grep 可以瞬間找到那些。其工作是找出 grep 不會呈現的破壞。
不要相信你自己的論述
一份描述變更會破壞什麼且聽起來合理的論述，是毫無價值的。無論它是否屬實，讀起來都令人信服。因此，不要交回那份論述。找出整個事情所依賴的一兩個事實，並透過執行程式碼來證明它們。
你有多確定
對於變更安全所依賴的每個事實，請盡可能地沿著這個列表往下進行（以低成本的方式），並說明它停留在哪個步驟。
- 你這麼說。本身毫無價值。
- 你指出了這一行。一個真實的
file:line，或函式庫本身的原始碼。 - 你展示了壞情況不可能發生。你逐步分析了失敗步驟，而它並未觸及。
- 你執行了它。一個腳本或測試，會呼叫真實程式碼，如果你錯了就會大聲失敗。
- 你在運行的應用程式中重現了它。
任何你無法達到步驟 4 的安全事實，請說明。不要將其論述為已解決。步驟 4 通常是一個小腳本，匯入應用程式使用的同一個函式庫，並呼叫你擔心的確切函式。
步驟
- 閱讀變更。差異、它新增、變更和刪除的符號，以及它現在做的不同事情，包括差異未明確說明的部分。提取 PR 和提交訊息以了解其背後的原因。
- 找到它之所以安全的那一個事實。大多數看似有風險的變更之所以安全，是因為一個單一事實，例如「這個呼叫只會丟棄已死的快取條目，不做其他任何事情」。找到那個事實。如果它成立，大多數有風險的情況就會立即被清除。在此處花費你的時間，而不是列出一長串可能的情況。
- 查看
grep停止的地方。閱讀你呼叫的函式庫的原始碼，並檢查其鎖定版本和任何本地修補程式。弄清楚事物何時執行：微任務、卸載和清理、Solid 與 React。追蹤符號搜尋遺漏的內容：API 返回的 JSON、資料庫欄位、有線格式、讀取相同位元組的另一種語言、功能標誌、下游三個跳躍的程式碼。 - 對每個風險誠實。給予它真正發生的可能性以及如果真的發生了的真實成本。保留你確認的風險。列出你檢查過並排除的風險，並分別說明。引用真實的
file:line，搜尋不到結果也是一個答案，絕不要捏造呼叫者或 API。 - 證明那一個事實。撰寫一個執行真實程式碼的腳本或測試，執行它，並貼上結果。如果你無法低成本地證明它，將其標記為未證明。不要誇大。
- 對於大型或廣泛的變更，使用上述審查流程並搭配多個模型來執行。不同的模型會捕捉不同的真實錯誤。
要交回的內容
- 它的作用。 變更了什麼，包括不明顯的部分。
- 它之所以安全的那一個事實。 陳述它，說明你將它推進到哪個步驟，並展示證明。如果你無法證明它，請寫「未證明」。
- 風險。 僅限真實的風險。每個風險需說明它如何破壞、
file:line、可能性和嚴重程度，以及如何檢查。對重要的風險貼上證明。 - 已排除。 你檢查過的內容以及它為何沒問題。
- 合併之前。 能夠捕捉真實錯誤的最便宜的測試或重現步驟，包括你撰寫的腳本。
透過 unslop 撰寫，引用真實程式碼，並在將其發布到任何公開場所之前，移除任何私人資訊。
回覆： 上述論述，其中一個安全性事實要嘛已證明，要嘛標記為未證明。