code-reviewlisted

對 `HEAD` 與使用者提供的固定點之間的 diff 做雙軸審查： - **規範（軸）**——程式碼是否符合此 repo 記錄的編碼規範？ - **規格（軸）**——程式碼是否忠實實作原始 issue / 規格？ 兩個軸都以**平行子代理**執行，讓它們不污染彼此的上下文，然後本技能匯總它們的發現。 Issue 追蹤器應該已經提供給你——如果 `docs/agents/issue-tracker.md` 缺失，執行 `/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 非空。壞的 ref 或空的 diff 應該在這裡失敗——而不是在兩個平行子代理內部。 ### 2. 找出規格來源 依此順序尋找原始規格： 1. commit 訊息中的 issue 引用（`#123`、`Closes #45`、GitLab `!67` 等）——透過 `docs/agents/issue-tracker.md` 中的工作流程擷取。 2. 使用者以參數傳入的路徑。 3. `docs/`、`specs/` 或 `.scratch/` 下符合分支名稱或功能的規格檔。 4. 如果什麼都沒找到，問使用者規格在哪。如果他們說沒有，**規格**子代理會跳過並回報「no spec available」。 ### 3. 找出規範來源 repo 中任何記錄程式碼應如何撰寫的東西，例如 `CODING_STANDARDS.md` 或 `CONTRIBUTING.md`。 在 repo 記錄的任何東西之上，規範軸永遠攜帶下面這份**壞味道基線**——一組固定的 Fowler 壞味道（_Refactoring_，第 3 章），即使 repo 什麼都沒記錄也適用。兩條規則綁定它： - **repo 優先。** 記錄在案的 repo 標準永遠勝出；當它背書基線會標記的某個東西時，抑制該壞味道。 - **永遠是判斷。** 每個壞味道都是帶標籤的啟發式（「可能是 Feature Envy」），從來不是硬性違規——而且像這裡的任何標準一樣，跳過任何工具已經強制的東西。 每個壞味道讀成*它是什麼* → *如何修*；把它對上 diff： - **神祕名稱（Mysterious Name）**——函式、變數或型別的名字看不出它做什麼或存什麼。→ 重新命名；如果想不出誠實的名字，設計很模糊。 - **重複程式碼（Duplicated Code）**——相同的邏輯形狀在變更中出現於多個 hunk 或檔案。→ 抽取共享形狀，兩邊都呼叫它。 - **特徵依附（Feature Envy）**——方法觸及另一個物件的資料比自己的多。→ 把方法移到它所羨慕的資料上。 - **資料叢集（Data Clumps）**——相同的幾個欄位或參數一直結伴同行（一個想出生的型別）。→ 把它們捆成一個型別，傳那個。 - **基本型別執著（Primitive Obsession）**——用