Principle Laziness Protocol

作者 cursorccb5507cec15無授權條款10K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫今天更新

Apply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading. Bias toward deletion and the smallest change that solves the problem.

AI 產生的概覽

指導重構時優先刪除、縮小差異並保持扁平呼叫階層,而非新增抽象。

功能
此技能提供一套用於重構與程式碼審查的準則:優先刪除而非新增、保持呼叫階層扁平、把重複決策集中到單一真實來源,並盡量縮小差異範圍。它也建議質疑那些要求把新訊號貫穿型別、結構描述或管線的任務,並清除細小的透傳與重複選擇。它產出的是指導原則與判斷標準,而不是檔案或程式碼成品。
適用情境
適用於重構程式碼、評估差異是否過大,或某項變更似乎需要引入新抽象、新階層或訊號貫穿時。它旨在推動採用能解決問題的最小變更。
執行需求
不需要任何工具、套件、執行環境、憑證或網路存取;它僅為說明性指示,不附帶指令碼。

Laziness Protocol

Aim for the most result with the least code and complexity.

  • Prefer deletion. When asked to refactor or improve, look for removals before additions.
  • Maintain a flat call hierarchy. Avoid deep call chains. A rich interface that hides substantial work is not a deep call chain. If answering a question requires tracing through more than 3 files or layers, flatten it.
  • Consolidate decisions. Do not repeat the same choice in several places. Put it behind one source of truth and pass the result as a simple flag.
  • Minimize the diff. Make the smallest change that solves the problem. Fewer lines beat "elegant" boilerplate.
  • Question the threading. If a task asks you to pass a new signal through types, schemas, pipelines, or similar layers, stop and look for a more direct path.
  • Sweat the small leaks. Remove tiny pass-throughs, representation leaks, and duplicated choices before they spread. Small leaks compound into permanent coordination costs.

The test: If a human developer would find the code exhausting to maintain, it is a bad solution.

來源與署名

來源:cursor/plugins位於pstack/skills/principle-laziness-protocol提交ccb5507

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架