使用者提供的固定點與 HEAD 之間差異的雙軸審查：
- 標準 — 程式碼是否符合此儲存庫文件化的編碼標準？
- 規格 — 程式碼是否忠實實作原始問題 / PRD / 規格？
兩個軸都作為平行子代理執行，這樣它們不會互相污染上下文，然後此技能彙整它們的發現。
問題追蹤器應已提供給你——如果缺少 docs/agents/issue-tracker.md，請執行 /setup-matt-pocock-skills。
流程
1. 固定固定點
無論使用者說了什麼固定點——提交 SHA、分支名稱、標籤、main、HEAD~5 等。如果他們沒有指定，請詢問。
捕獲一次差異指令：git diff <fixed-point>...HEAD（三點，因此比較的是合併基礎）。也要記錄 git log <fixed-point>..HEAD --oneline 的提交清單。
在繼續之前，確認固定點可以解析（git rev-parse <fixed-point>）且差異不為空。錯誤的引用或空差異應在此處失敗——而不是在兩個平行子代理內部。
2. 識別規格來源
尋找原始規格，按此順序：
- 提交訊息中的問題引用（
#123、Closes #45、GitLab!67等）——透過docs/agents/issue-tracker.md中的工作流程擷取。 - 使用者作為引數傳遞的路徑。
docs/、specs/或.scratch/下符合分支名稱或功能的 PRD/規格檔案。- 如果找不到，問使用者規格在哪裡。如果他們說沒有，規格子代理將跳過並報告「無可用規格」。
3. 識別標準來源
儲存庫中任何說明程式碼應如何撰寫的資料，例如 CODING_STANDARDS.md 或 CONTRIBUTING.md。
除了儲存庫文件化的內容之外，標準軸始終包含下面的異味基準——一組固定的 Fowler 程式碼異味（《重構》，第3章），即使儲存庫沒有文件化任何內容也適用。有兩個規則約束它：
- 儲存庫覆蓋。 文件化的儲存庫標準始終優先；在它認可基準會標記的內容時，抑制該異味。
- 始終是裁量判斷。 每個異味都是一個帶標籤的啟發式方法（「可能的 Feature Envy」），絕非硬性違規——而且，像此處的任何標準一樣，跳過工具已經強制執行的任何內容。
每個異味會說明它是什麼 → 如何修復；將其與差異比對：
- 神秘名稱 — 一個函式、變數或型別，其名稱未揭示它的作用或包含的內容。→ 重新命名；如果想不到誠實的名稱，設計就很模糊。
- 重複程式碼 — 相同的邏輯形狀出現在變更中的多於一個區塊或檔案中。→ 提取共享的形狀，從兩處呼叫它。
- 特徵依戀 — 一個方法存取另一個物件資料的次數多於自己的資料。→ 將方法移到它依戀的資料上。
- 資料泥團 — 相同的幾個欄位或參數總是一起出現（一個渴望被創造的型別）。→ 將它們捆綁到一個型別中，傳遞那個型別。
- 基本型別 obsession — 一個基本型別或字串代表一個應該擁有自己型別的領域概念。→ 給該概念自己的小型型別。
- 重複開關 — 相同型別上的相同
switch/if級聯在變更中重複出現。→ 用多型取代，或使用兩處共享的一個對應表。 - 散彈式修改 — 一個邏輯變更迫使變更中的許多檔案進行分散的編輯。→ 將一起變更的內容收集到一個模組中。
- 發散式變更 — 一個檔案或模組因幾個不相關的原因被編輯。→ 拆分，使每個模組只為一個原因變更。
- 投機性通用化 — 為規格沒有的需求新增的抽象化、參數或鉤子。→ 刪除它；內聯回來，直到出現真正的需求。
- 訊息鏈 — 呼叫者不應依賴的長
a.b().c().d()導航。→ 將遍歷隱藏在第一個物件上的一個方法後面。 - 中間人 — 一個主要只是委派給別人的類別或函式。→ 切掉它，直接呼叫真正的目標。
- 拒絕的遺贈 — 一個忽略或覆蓋大部分它所繼承內容的子類別或實作者。→ 放棄繼承，使用組合。
4. 平行生成兩個子代理
發送一條帶有兩個 Agent 工具呼叫的訊息。對兩者都使用 general-purpose 子代理。
標準子代理提示 — 包含：
- 完整的差異指令和提交清單。
- 你在步驟3中找到的標準來源檔案清單，加上步驟3中的異味基準完整貼上——子代理沒有其他存取它的方式。
- 簡要說明：「報告 — 在相關的每個檔案/區塊中：(a) 差異違反文件化標準的每個地方：引用標準（檔案 + 規則）；以及 (b) 你發現的任何基準異味：命名它並引用該區塊。區分硬性違規與裁量判斷——文件化標準的違規可能是硬性的，但基準異味始終是裁量判斷，且文件化的儲存庫標準覆蓋基準。跳過工具強制執行的任何內容。少於 400 字。」
規格子代理提示 — 包含：
- 差異指令和提交清單。
- 規格的路徑或擷取的內容。
- 簡要說明：「報告：(a) 規格要求但缺失或不完整的需求；(b) 差異中未被要求的行為（範圍蔓延）；(c) 看起來已實作但實作方式錯誤的需求。為每個發現引用規格行。少於 400 字。」
如果規格缺失，跳過規格子代理並在最終報告中註明。
5. 彙整
在 ## 標準 和 ## 規格 標題下逐字或輕微清理後呈現兩個報告。不要合併或重新排序發現——這兩個軸是刻意分開的（請參閱為什麼要分兩個軸）。
最後以一行摘要結束：每個軸的發現總數，以及每個軸內最差的問題（如果有的話）。不要跨軸選出單一獲勝者——那正是此分離旨在防止的重新排序。
為什麼要分兩個軸
一個變更可以通過一個軸但未通過另一個軸：
- 遵循每項標準但實作了錯誤內容的程式碼 → 標準通過，規格未通過。
- 完全按問題要求做但違反專案慣例的程式碼 → 規格通過，標準未通過。
分開報告它們可以防止一個軸掩蓋另一個軸。