thermo-nuclear-code-quality-review | 嚴格檢查結構與維護成本
本頁以 pstack-claude 0.9.126 的移植版技能為準。此技能不在本次核對的 Cursor 原版 pstack 技能目錄中，不應被當成 Cursor 原版內建審查。
定位與適用情境
這個技能檢查「行為正確但結構變差」的變更。重點是維護性、抽象品質與邊界，不是把每個命名偏好都變成阻擋意見。
例如結帳分支把原本 940 行的協調模組擴成 1080 行，又在三個通用流程插入會員優惠判斷。輸入是分支差異、修改前後的檔案與測試契約。審查要問能否把優惠責任放回既有政策層，讓整組條件分支消失，而不是只把分支搬到更多檔案。
準備
- 指定審查範圍與必須保持的行為。準備既有層級、共用工具與狀態模型的入口。
- 取得修改前後檔案，才有依據說是此分支造成檔案膨脹或耦合增加。
- 指定可寫的報告目錄。原文要求一份摘要與每子系統或每審查者的詳細報告，不是一個巨型檔案。
- 若要量測行數或執行測試，記錄實際命令、版本與輸出。未執行的重構提案要標成提案。
操作步驟
- 描出責任與增量。 讀差異及周邊程式，確認新增邏輯屬於哪一層，是否重複既有標準工具，以及檔案是否因這次變更跨過 1000 行。
- 找能刪除複雜度的轉法。 原文稱為 code judo，意指藉由重整模型或擁有權，刪除整層包裝、模式與分支。先找更直接的流程，不預設「新增一個抽象」就是改善。
- 檢查型別與協調邊界。 查看多餘可選欄位、
any、轉型、靜默備援、薄包裝與錯層邏輯。也檢查明明獨立卻被串行化的工作，以及相關更新可能只完成一半的狀態。 - 按結構影響排序。 先列結構退化與明顯錯失的簡化，再列分支、契約、檔案大小、模組化與可讀性。每個高信心問題說明證據、行為不變的改善方向及取捨，不淹沒在細碎格式建議中。
- 分層交付。 摘要約 200 行，寫判斷、每項問題的敘述段落、修復順序與詳細報告連結。細節檔保留命令、量測、驗證狀態與展開的重構提案。若使用 swarm，保留每位審查者的細節報告，不丟棄它們。
可直接使用的提示詞
Claude Code 可用 /pstack:thermo-nuclear-code-quality-review，Codex 插件可選 $pstack:thermo-nuclear-code-quality-review。
用 pstack:thermo-nuclear-code-quality-review 審查目前結帳分支，只寫報告。
先核對修改前後的結帳協調模組行數與責任，不把假設數字當實測。
重點是會員優惠判斷是否散入通用流程，以及能否用既有政策層刪除整組分支。
保留行為契約，檢查薄包裝、轉型、重複工具、半套更新與不必要串行化。
給少量高信心的結構問題，附真實檔案位置、證據與可行改善方向。
在我指定的報告目錄寫摘要與各子系統細節，保留實際命令及驗證狀態。
不修改應用程式，不因測試通過就直接認可維護性。預期結果與驗收
- 摘要能一次讀完，每個重要問題都指向詳細證據，不是一長串碎片標籤。
- 原本低於 1000 行、這次超過 1000 行的檔案會被明確提出。這是需強理由的結構警訊，不是所有長檔案一律必須切開。
- 提案說清楚哪些概念、分支或層會被刪掉。只搬移同樣複雜度不算證明改善。
- 型別與抽象建議連回可理解的不變條件，不只是偏好某種語法。
- 認可標準還包含沒有明顯結構退化、錯層、重複標準工具或無理由膨脹。功能測試通過並不足夠。
限制與權限
這是嚴格維護性審查，不是形式證明，也不取代安全與正確性稽核。千行門檻、可平行化與原子更新建議都要依實際架構判斷，不能為追求指標而拆散凝聚模組或改壞相依順序。
原文鼓勵大幅簡化，但審查建議不構成廣泛重寫授權。範例只授權報告，實作與驗證新設計要另行確認範圍。
沒有多代理工具仍可單獨審查，但不能聲稱有獨立多人結論。報告檔案若不在授權目錄，先交代阻塞，不自行改寫共享文件。