| 1 | --- |
| 2 | name: principle-laziness-protocol |
| 3 | description: "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." |
| 4 | disable-model-invocation: true |
| 5 | --- |
| 6 | |
| 7 | # Laziness Protocol |
| 8 | |
| 9 | Aim for the most result with the least code and complexity. |
| 10 | |
| 11 | - **Prefer deletion.** When asked to refactor or improve, look for removals before additions. |
| 12 | - **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. |
| 13 | - **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. |
| 14 | - **Minimize the diff.** Make the smallest change that solves the problem. Fewer lines beat "elegant" boilerplate. |
| 15 | - **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. |
| 16 | - **Sweat the small leaks.** Remove tiny pass-throughs, representation leaks, and duplicated choices before they spread. Small leaks compound into permanent coordination costs. |
| 17 | |
| 18 | **The test:** If a human developer would find the code exhausting to maintain, it is a bad solution. |