principle-laziness-protocol

name	principle-laziness-protocol
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.
license	MIT
metadata	{"tags":"refactoring,scope,simplicity","groups":"execution-principles","invocation":"user","source":"https://github.com/cursor/plugins@195d9359bdc2890f83745df69927528ad4538406:pstack/skills/principle-laziness-protocol"}

Laziness Protocol

Writing code is cheap for you, which makes over-engineering easy. Counter it by borrowing a human maintainer's fatigue. 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.

Prime directive: If a human developer would find the code exhausting to maintain, it is a bad solution. Be lazy. Stay simple.