Principle Laziness Protocol

by cursorccb5507cec15No license10K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated today

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.

Instructions onlySoftware Development
AI-generated overview

Guides refactoring toward deletion, minimal diffs, and flat call hierarchies instead of added abstractions.

What it does
This skill provides a set of coding heuristics for refactoring and code review: prefer deletion over addition, keep call hierarchies flat, consolidate repeated decisions behind one source of truth, and keep diffs as small as possible. It also advises questioning requests to thread new signals through types, schemas, or pipelines, and removing small pass-throughs and duplicated choices. It produces guidance and judgment criteria rather than files or code artifacts.
When to use it
Use it when refactoring code, evaluating whether a diff is too large, or when a change seems to require new abstractions, layers, or signal threading. It is meant to push toward the smallest change that solves the problem.
Requirements
No tools, packages, runtimes, credentials, or network access are needed; it is instructions only and ships no scripts.

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.

Source and attribution

Source:cursor/pluginsinpstack/skills/principle-laziness-protocolat commitccb5507

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal