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.
Installs into .claude/skills of the current project.
Are you the author of Principle Laziness Protocol?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/edbertchan-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."
disable-model-invocation: true
---
# 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.
**Before deleting, check twice:**
- Uncommitted work under the file you're about to delete? Run `git status`/`git diff --stat` on it first — don't delete on the strength of "it's redundant" alone.
- A test named after the thing you're deleting can still guard a general invariant that has nothing to do with that specific thing. Read what it actually asserts before deleting it alongside the code — rewire it to whatever's generic and keep it running. "Delete the dead code's tests" is not the same task as "delete the invariant's only test."
## Related
- `principle-foundational-thinking` — the one decision this principle should
not defer. Both reject building more than the problem needs, but a data
shape is the exception: late it is a rewrite, early it is often a one-line
diff. Do less, except about the core structure.
