ce-simplify-code

簡化最近變更的程式碼，在嚴格保持既有行為的前提下提升可讀性、複用性、品質與效率。優先考慮清晰易讀、意圖明確的程式碼，而非精簡過度的程式碼——減少程式碼行數並不是我們的目標。

Setup

在本次執行的開頭、派發任何 Subagent 之前執行一次此指令，並遵循其輸出的指引——除非該指引與本 Skill 本身關於「詢問使用者問題」的規則發生衝突（無論這些規則僅適用於非互動模式或適用於所有模式），此時以本 Skill 的規則為準，且不提出阻塞性問題。請完全照原樣單獨執行區塊中的指令：切勿使用管道或過濾器（例如 head、tail 或 grep），切勿截斷其輸出，也不要將其與其他指令合併批次處理。其輸出會以 === skill context 標頭開始，並以 CE_CONTEXT_END 結尾；若你只收到其中一行而缺乏另一行，代表輸出已被截斷——請照原樣重試執行一次區塊。此修復重試是唯一的重試機會，否則在同一次執行中切勿重複執行；後續若有此 Skill 或其他 Skill 的執行，將會各自運行其內部的指令。若無可用的 Node 執行階段（Node runtime），本 Skill 將直接按正常流程繼續執行。

SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi

Step 1: 確定簡化範圍

按以下順序解析簡化範圍：

1. 若使用者明確指定了範圍（例如某個檔案、目錄、「我剛剛寫的函式」、「今天早上的變更」），則直接使用該範圍。請將使用者指定的範圍視為權威依據——切勿擅自擴大範圍。
2. 否則，若在 Git 儲存庫中，預設為當前分支與其基底分支之間的差異（例如 git diff origin/main... 或對比已設定的上游分支）。這涵蓋了常見的使用場景：「在發起 PR 前，簡化我在這個功能分支上新增的所有內容」。若該分支沒有上游或基底引用（base ref），則退回使用已暫存與未暫存的變更（git diff HEAD）。
3. 若不在 Git 儲存庫中或無法取得差異（Diff），請審視使用者提及的或在本對話早期編輯過的最新修改檔案。

若上述方式皆無法產生非空範圍，請停止並詢問使用者要簡化哪些內容，切勿隨意猜測。請使用平台的阻塞性提問工具：Claude Code 中的 AskUserQuestion（若 Schema 未載入，先呼叫 ToolSearch 並帶入 select:AskUserQuestion）、Codex 中的 request_user_input、Antigravity CLI (agy) 中的 ask_question、Pi 中的 ask_user（需要 pi-ask-user 擴充功能）。只有當執行環境中不存在阻塞性工具或呼叫出錯（例如 Codex 編輯模式）時，才退回使用聊天介面中的編號選項——絕不能只因為需要載入 Schema 就退回。切勿默默跳過提問。

預檢（Preflight）——在派遣審查員前先跳過無實質產出的範圍。 三位審查員主要在程式碼中尋找複用性、品質與效率問題。若解析出的範圍內不包含實質的人工撰寫程式碼——例如僅有文件/Markdown，或純粹是自動生成的檔案、第三方庫（vendored）、依賴包/lockfile，或純機械性的變更（格式化、lint 自動修復、批量重命名）——請在此處停止並輸出一行簡短說明（表示沒有需要簡化的內容），且不要派遣審查員。若為混合型 diff（既包含真實程式碼也包含上述無產出的變更），請將範圍縮小至程式碼檔案後繼續。此預檢僅依據變更的類型進行過濾，絕不依據變更的大小或數量：使用者明確指定的範圍具有權威性，即使範圍很小也仍會執行。（已自行控管大小/成本的呼叫者——如 ce-work、lfg——以及任何常駐的「自動執行」指令擁有其大小/成本策略；此預檢僅作為無程式碼時的安全防護網。）

當預檢通過後，若平台支援任務追蹤功能（Task tracking），請利用該功能向使用者展示基於剩餘工作流程衍生出的簡短檢視畫面。請追蹤具體有意義的審查、套用與驗證結果，而不是為每個審查員建立一個任務或照搬每個步驟；僅在觸發條件成立時才新增條件性工作。若無可用的任務追蹤功能，請正常繼續執行，無需在對話中模擬任務清單。

Step 2: 平行啟動 3 個審查 Agent

透過平台的 Subagent 原生功能（例如 Claude Code 中的 Agent/Task，Codex 中的 spawn_agent）派遣三個通用 Subagent：程式碼複用性（code-reuse）、程式碼品質（code-quality）與效率（efficiency）審查員；若無此類原生功能，則以行內（inline）或串行方式執行審查。對於每位審查員，請從本 Skill 的目錄中讀取其 Prompt 資產，並將完整檔案內容連同已解析的範圍（完整 diff 或檔案集合）一併作為 Subagent 的 Prompt 傳遞，以使其具備完整的上下文資訊：

• references/personas/code-reuse-reviewer.md —— 現有工具函式、重複功能、重新實現的標準庫/執行階段原語。
• references/personas/code-quality-reviewer.md —— 冗餘狀態、參數過度膨脹、複製貼上、抽象洩漏（leaky abstractions）、字串型別化程式碼（stringly-typed code）、死碼（dead code）、過度嵌套，以及防止過度簡化的平衡守衛。
• references/personas/efficiency-reviewer.md —— 不必要的工作、錯失的平行處理機會、熱點路徑（hot-path）膨脹、無效更新（no-op updates）、記憶體洩漏。

切勿憑記憶改寫這些評分標準——請務必讀取每個檔案並原樣完整傳遞，否則審查員將失去確保行為一致性的過濾規則。

受限派發（Bounded dispatch）。 將三位審查員加入佇列，且僅啟動執行環境目前允許的最大數量；若遇到並行度/活躍 Agent 限制錯誤，請將其視為背壓（Backpressure，保持審查員在佇列中，待有空位後重試），而非審查員失敗。

模型選擇（Model selection）。 當當前執行環境提供已知覆寫選項時，為這些審查員使用平台的中階平衡模型。在 Claude Code 中即為 Sonnet 層級。在 Codex 中，僅當活躍的派發原語提供明確的模型或自訂 Agent 選擇器時才套用此層級；僅憑任務描述文字不會自動選擇不同模型。否則請忽略覆寫並繼承主 Agent 的模型——在主 Agent 模型上正常運作的審查，比派發失敗更為重要。

權限模式（Permission mode）。 在派發呼叫中省略 mode 參數，以便套用使用者所設定的權限設定。

Step 3: 修復問題

等待所有三個 Agent 完成。彙整它們的發現並直接修復各個問題。若某個審查發現屬於誤報（false positive）或不值得處理，記錄後直接跳過即可。切勿與該發現爭辯或向使用者提出疑問，直接跳過即可。

在套用每個修復之前，請確認其能完全保持原有行為：相同輸入產生相同輸出、錯誤處理行為一致、副作用與執行順序維持不變。若修復無法通過此驗證，請跳過它——Step 4 中的自動化檢查無法涵蓋所有行為細節。

切勿為了簡化而移除安全檢查。 信任邊界處的輸入驗證、防止資料遺失的錯誤處理、安全性檢查（授權、轉義、淨化）以及無障礙輔助設計（accessibility affordances）並非可隨意移除的冗餘程式碼——即使審查發現將其歸類為冗餘或可行內化（inline-able），也必須予以保留。移除這些內容的程式碼並非更簡潔，而是未完成。若建議的簡化會削弱或移除上述任何一項，請直接跳過。

遵循呼叫者傳遞的結構固定約束（structure pins）。 當呼叫者傳入帶有結構固定約束的計畫路徑時，該計畫路徑僅作為上下文，絕非簡化的目標範圍；該計畫中標註有 session-settled: 的關鍵技術決策（Key Technical Decisions）屬於簡化過程必須保留的結構性約束——特意重複的檔案保持重複、特意獨立的實現保持獨立——即使合併整合看起來是最顯而易見的簡化手段也是如此。保持既有行為已約束了每個修復；此規則將其進一步延伸至已決定的架構結構。

Step 4: 驗證行為是否完好保留

本 Skill 的核心前提是：簡化必須百分之百保留原有的功能。套用修復後：

對整個專案執行型別檢查（Typecheck）與 Lint。 它們通常速度很快，且能捕捉最常見的簡化退化問題——例如無效的引用/匯入（import）、未使用的匯出（export）、被遺漏的型別收窄（type narrowings），或仍被其他模組引用的死碼。

執行測試：

• 執行針對受變更路徑的測試。CI 會在 PR 時執行完整測試套件——此處的本地檢查旨在快速提供訊號，而非最終保證。請根據影響範圍（blast radius）匹配測試範圍；僅 3 行的簡化不值得執行長達 20 分鐘的完整測試。
• 當變更具有明顯廣泛的影響時擴大測試範圍——例如重新撰寫了被大量引用的工具函式，或是程式碼品質審查員的合併/去重修復修改了共用程式碼。這是對波及風險的專業判斷，而非死板的規則。
• 若測試執行器（test runner）沒有範圍限制機制，則執行完整測試套件。

清楚展示任何失敗訊息，包含失敗的檢查名稱與相關輸出。切勿為了讓檢查通過而放寬斷言（assertions）、削弱型別簽名或跳過測試——這會破壞「保留功能」的保證。請修復由簡化引入的底層損壞，或還原（revert）導致功能退化的特定變更。

若未設定測試套件、Lint 或型別檢查，請在摘要中明確說明；切勿默默跳過驗證步驟。

Step 5: 撰寫摘要

簡要總結程式碼原本良好的部分，以及改進與修復的內容，並包含執行的檢查項目及其結果。若沒有需要處理的審查發現，請確認程式碼無需進行任何變更。

按維度量化影響。 報告實際套用的修復內容，而非行數統計：各審查員維度套用的修復數量（複用性、品質、效率）、多少項審查發現因誤報或不值得處理而被跳過，以及行為保留的驗證結果（執行的檢查與結果）。例如：「已套用 6 項——複用性 2、品質 3、效率 1；跳過 2 項誤報；型別檢查 + Lint 通過，11 項局部測試通過。」切勿將「淨移除行數」作為標題焦點，或將行數減少視為主要成果——許多關於清晰度、安全性與效率的修復可能會保留甚至增加程式碼行數。衡量標準在於改進了哪些內容且原有行為完好無損，而非程式碼縮減了多少。