Principle Laziness Protocol

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.

v1truv1us f9700a0 1.2 KB Updated

File contents

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 hierarchy. Avoid deep abstractions. 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.

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

v1truv1us/ai-eng-system/tree/main/.gemini/skills/pstack/principle-laziness-protocol commit f9700a0836

Frequently asked questions

npx skillmds add v1truv1us-ai-eng-system/principle-laziness-protocol