principle-laziness-protocol
cursor/plugins
Bias toward deletion and minimal changes—apply when refactoring, evaluating diffs, or tempted by abstractions.
What is principle-laziness-protocol?
A protocol for keeping code simple and maintainable by preferring deletion, flat hierarchies, and the smallest change that solves the problem. Use it when refactoring, reviewing diffs, or considering new abstractions, layers, or signal threading.
- Prefer deletion over addition when refactoring or improving code
- Maintain flat call hierarchies—avoid deep chains and unnecessary layers
- Consolidate repeated decisions into a single source of truth
- Make the smallest diff that solves the problem, favoring fewer lines over boilerplate
- Question whether new signals need threading through types, schemas, or pipelines
- Remove small leaks and pass-throughs before they compound into coordination costs
How to install principle-laziness-protocol
npx skills add https://github.com/cursor/plugins --skill principle-laziness-protocolHow to use principle-laziness-protocol
- 1.When asked to refactor or improve code, first look for what can be removed rather than added
- 2.Check call hierarchies—if tracing a question requires more than 3 files or layers, consider flattening
- 3.Identify repeated decisions and consolidate them behind a single source of truth
- 4.Make the smallest change that solves the problem; resist adding elegant boilerplate
- 5.Before threading a new signal through types or pipelines, look for a more direct path
- 6.Scan for small pass-throughs and representation leaks and remove them early
Use cases
- Reviewing a refactoring proposal to decide whether to add a new abstraction layer
- Evaluating a diff to identify opportunities for simplification or deletion
- Deciding whether to thread a new parameter through multiple function signatures
- Assessing whether a helper function or utility is worth the indirection cost
- Identifying representation leaks or duplicated logic that should be consolidated
- Software engineers refactoring existing code
- Code reviewers evaluating diff size and complexity
- Architects deciding on abstraction boundaries
- Teams maintaining large codebases with coordination costs
principle-laziness-protocol FAQ
Apply it when refactoring, evaluating diff size, reviewing abstractions, or tempted to add layers or signal threading. It's a decision-making filter, not a rule to follow blindly.
No. It means achieving results with the least code and complexity—favoring clarity and maintainability over unnecessary abstraction or boilerplate.
If answering a question requires tracing through more than 3 files or layers, it's likely too deep. Flatten it so the logic is easier to follow.
A small leak is a tiny pass-through, representation leak, or duplicated choice. Left unchecked, these compound into permanent coordination costs across the codebase.
Not always—but question whether the helper is worth the indirection. If a human developer would find the code exhausting to maintain, it's a bad solution.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
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." disable-model-invocation: true
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.
Related skills
More from cursor/plugins and the wider catalog.
principle-make-operations-idempotent
Design operations to converge to correct state regardless of crashes, restarts, or retries.
principle-migrate-callers-then-delete-legacy-apis
Migrate callers and delete legacy APIs in one refactor wave instead of maintaining compatibility layers.
principle-minimize-reader-load
Reduce code complexity by minimizing reader cognitive load—collapse unnecessary layers and shrink mutable state.
principle-model-the-domain
Encode domain logic in structures instead of scattered conditionals and repeated assumptions.
principle-never-block-on-the-human
Proceed with reversible work without asking permission; reserve confirmation for irreversible actions only.
principle-outcome-oriented-execution
Prioritize end-state correctness over intermediate stability during planned rewrites and migrations.