對 HEAD 與使用者提供的固定點之間差異的雙軸向審查：
- 標準：程式碼是否遵循此儲存庫的文件化編碼標準？
- 規格：程式碼是否忠實實作了原始問題/規格？
兩個軸向作為 並行子代理 執行，因此不會污染彼此的上下文，然後此技能會彙總它們的發現。
問題追蹤器應已提供給您。如果沒有，請告訴使用者執行 /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/、specs/或.scratch/下與分支名稱或功能匹配的規格檔案。 - 如果找不到任何內容，詢問使用者規格在哪裡。如果他們說沒有，規格子代理將跳過並報告「無可用規格」。
3. 識別標準來源
搜尋儲存庫中所有記錄程式碼撰寫方式的檔案。當存在 CODING_STANDARDS.md 或 CONTRIBUTING.md 時，它們必須在列表中。
除了儲存庫文件化的內容之外，標準軸向始終攜帶以下異味基準：一組固定的 Fowler 程式碼異味（來自《重構》第 3 章），即使儲存庫沒有記錄任何內容，這些異味也適用。有兩條規則約束它：
- 儲存庫覆蓋。 文件化的儲存庫標準始終優先；若它認可了基準會標記的內容，則抑制該異味。
- 始終是判斷。 每種異味都是一個標籤化的啟發式方法（「可能的特徵依戀」），絕非硬性違規。與此處的任何標準一樣，跳過任何工具已強制執行的內容。
每種異味閱讀方式為「它是什麼」→「如何修復」；將其與差異比對：
- 神祕名稱：一個函式、變數或類型的名稱無法揭示其作用或內容。→ 重新命名；如果想不到合適的名稱，則表示設計不清晰。
- 重複程式碼：相同的邏輯模式出現在變更中的多個區塊或檔案中。→ 提取共享的模式，從兩處呼叫。
- 特徵依戀：一個方法存取另一個物件的資料多於存取自己的資料。→ 將方法移動到它所依戀的資料上。
- 資料泥團：相同的幾個欄位或參數一直一起出現（一個等待被創建的類型）。→ 將它們捆綁成一個類型，傳遞該類型。
- 基本型別偏執：使用基本型別或字串來代表一個值得擁有自己類型的領域概念。→ 為該概念建立自己的小型類型。
- 重複的 switch：對相同類型的相同
switch/if-cascade 在變更中重複出現。→ 用多型取代，或使用兩個位置共享的一個映射。 - 散彈式修改：一個邏輯變更需要遍及差異中許多檔案的零散修改。→ 將一起變更的內容收集到一個模組中。
- ** divergent 式修改**：一個檔案或模組因多個不相關的原因被編輯。→ 拆分，使每個模組只因一個原因而變更。
- 臆測性通用化：為規格不需要的需求而新增的抽象、參數或鉤子。→ 刪除它；內聯回去，直到出現真正的需求。
- 訊息鏈：長長的
a.b().c().d()導航，呼叫者不應該依賴它。→ 將遍歷隱藏在第一個物件的一個方法後面。 - 中間人：一個主要負責委派給其他物件的類別或函式。→ 刪除它，直接呼叫真實目標。
- 被拒絕的遺贈：一個子類別或實作者忽略或覆寫了大部分繼承的內容。→ 放棄繼承，改用組合。
4. 並行生成兩個子代理
同時發出兩個子代理呼叫（在前景中），並彙總它們返回的報告。
標準子代理提示應包含：
- 完整的差異指令和提交列表。
- 您在步驟 3 中找到的標準來源檔案列表，加上步驟 3 中的異味基準，完整貼上（子代理無法另行取得）。
- 簡要說明：「報告：針對每個相關檔案/區塊，(a) 差異違反文件化標準的每個地方：引用標準（檔案 + 規則）；(b) 您發現的任何基準異味：命名它並引用該區塊。區分硬性違規與判斷：文件化標準的違規可能是硬性的，但基準異味始終是判斷，且文件化的儲存庫標準會覆蓋基準。跳過任何工具已強制執行的內容。少於 400 字。」
規格子代理提示應包含：
- 差異指令和提交列表。
- 規格的路徑或取得的內容。
- 簡要說明：「報告：(a) 規格要求的但缺失或不完整的需求；(b) 差異中未被要求的行為（範圍蔓延）；(c) 看似已實作但實作方式看起來有誤的需求。為每個發現引用規格中的具體行。少於 400 字。」
如果規格缺失，則跳過規格子代理，並在最終報告中註明。
5. 彙總
將兩個報告分別放在 ## 標準 和 ## 規格 標題下，按原樣或稍加清理呈現。不要合併或重新排列發現，因為兩個軸向是刻意分開的（參見_為什麼是兩個軸向_）。
以一行摘要結尾：每個軸向的發現總數，以及_每個軸向內_最嚴重的問題（如果有）。不要跨軸向選擇一個優勝者：這就是分離所要防止的重新排名。
為什麼是兩個軸向
一個變更可能通過一個軸向而未能通過另一個軸向：
- 遵循所有標準但實作了錯誤功能的程式碼 → 標準通過，規格失敗。
- 完全按照問題要求但破壞了專案慣例的程式碼 → 規格通過，標準失敗。
分別報告它們可以防止一個軸向掩蓋另一個軸向。