最小程式碼自律 是做什麼的？
使用本技能在規劃與撰寫程式碼變更時，套用最小程式碼（YAGNI 階梯）規範。它能讓差異（diff）保持小巧且明顯正確，同時不犧牲確保使用者安全的檢查。
本技能與 ai-slop-cleaner 相輔相成：該技能在程式碼落地後清理多餘內容；而本技能則防止多餘程式碼被寫入。
使用時機
在以下情況使用本技能：
- 使用者要求最小化、精簡、YAGNI 或最小可能差異的實作
- 計劃或正在進行的變更已超出原始請求的範圍
- 正在撰寫可能出現範圍蔓延、重造輔助函式或投機式一般化的新程式碼
- 在實作前審查提議的差異大小
不使用時機
在以下情況不要使用本技能：
- 使用者明確要求廣泛、功能豐富或具未來擴充性的建置（其明確範圍優先）
- 任務是使用者標記為可拋棄的探索性原型
- 最小化壓力會觸及受保護的行為（請參閱「不可妥協事項」）
規範
存在優先。 先問變更是否需要存在；跳過僅服務於投機性未來需求的工作。
重用優先於撰寫。 在撰寫任何新程式碼前，先搜尋程式碼庫中是否已有現成的輔助函式、型別或模式。切勿複製已存在於附近檔案中的輔助函式 — 應重用或將其提取至一個共用位置。
依賴階梯。 優先使用標準函式庫，其次才是平台原生能力，再來是已安裝的依賴項。手寫程式碼是最後的手段。當幾行程式碼足以解決問題時，不要引入新的依賴項，除非使用者明確要求或同意。
在最小化前先理解。 先閱讀受影響的程式碼並追蹤其執行路徑。一旦理解問題，再送出最短的正確差異 — 從未撰寫的程式碼永遠不會出錯。
樸實勝於取巧。 偏好樸實、明顯正確的程式碼，而非取巧的程式碼。
標記上限。 以簡短註解記錄刻意簡化的內容，命名所接受的上限以及未來可證明需要替換它的理由。
根本原因，而非症狀。 在每個呼叫端共用的根本原因處修復錯誤，而不是為每個回報的症狀分別打補丁。
不可妥協事項
絕不能因最小化而捨棄：
- 任何跨越信任邊界時的驗證
- 防止資料遺失的錯誤處理
- 安全控制
- 可及性基礎
- 使用者明確要求的範圍
驗證
在回報完成前，請確認：
- 每一行新增的程式碼都有其存在的理由（沒有投機式一般化，沒有重複的輔助函式）
- 差異是正確解決所述問題的最短版本
- 不可妥協事項完好無損
- 測試仍然通過，且行為除要求變更外未改變