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