對 HEAD 與使用者提供的固定點之間差異的雙軸線審查：
- 標準 — 程式碼是否符合此儲存庫的文件化編碼標準？
- 規格 — 程式碼是否忠實實作原始議題 / PRD / 規格？
兩個軸線會作為平行子代理執行，以避免彼此上下文污染，然後此技能會彙總它們的發現。
應已提供議題追蹤器給您 — 如果缺少 docs/agents/issue-tracker.md，請執行 /setup-matt-pocock-skills。
流程
1. 固定固定點
無論使用者指定的是什麼固定點 — 提交 SHA、分支名稱、標籤、main、HEAD~5 等。如果他們沒有指定，請詢問。
一次擷取 diff 指令：git diff <固定點>...HEAD（三點，以便與合併基準進行比較）。同時透過 git log <固定點>..HEAD --oneline 記錄提交清單。
在繼續之前，確認固定點可以解析（git rev-parse <固定點>）且 diff 非空。無效的引用或空的 diff 應在此處失敗，而不是在兩個平行子代理內部。
2. 識別規格來源
尋找原始規格，依此順序：
- 提交訊息中的議題參考（
#123、Closes #45、GitLab!67等）——透過docs/agents/issue-tracker.md中的工作流程擷取。 - 使用者作為引數傳遞的路徑。
- 位於
docs/、specs/或.scratch/下，且與分支名稱或功能相符的 PRD/規格檔案。 - 如果找不到任何內容，請詢問使用者規格在哪裡。如果他們說沒有，規格子代理將跳過並報告「無可用規格」。
3. 識別標準來源
儲存庫中任何記錄程式碼應如何撰寫的內容，例如 CODING_STANDARDS.md 或 CONTRIBUTING.md。
4. 平行啟動兩個子代理
使用兩個 Agent 工具呼叫發送單一訊息。對兩者都使用 general-purpose 子代理。
標準子代理提示 — 包含：
- 完整的 diff 指令和提交清單。
- 您在步驟 3 中找到的標準來源檔案清單。
- 簡報：「報告——在相關的每個檔案/區塊中——diff 中違反文件化標準的每個地方。引用標準（檔案 + 規則）。區分嚴格違規與判斷性問題。跳過任何工具會強制執行的內容。少於 400 字。」
規格子代理提示 — 包含：
- diff 指令和提交清單。
- 規格的路徑或擷取的內容。
- 簡報：「報告：(a) 規格要求但遺失或不完整的需求；(b) diff 中未要求但出現的行為（範圍蔓延）；(c) 看起來已實作但實作方式看起來有誤的需求。為每個發現引用規格行。少於 400 字。」
如果缺少規格，請跳過規格子代理，並在最終報告中註明。
5. 彙總
在 ## Standards 和 ## Spec 標題下呈現兩個報告，逐字或經過輕微清理。不要合併或重新排序發現結果——這兩個軸線是刻意分開的（見_為何分為兩個軸線_）。
以一行摘要結尾：每個軸線的發現總數，以及每個軸線內最嚴重的問題（如果有的話）。不要在軸線之間選擇單一贏家——這就是分離旨在防止的重新排序。
為何分為兩個軸線
變更可能通過一個軸線而失敗於另一個軸線：
- 遵循所有標準但實作了錯誤內容的程式碼 → 標準通過，規格失敗。
- 完全按照議題要求實作但打破了專案慣例的程式碼 → 規格通過，標準失敗。
分別報告它們可以防止一個軸線掩蓋另一個軸線。