principle-laziness-protocol

Guides code refactoring toward deletion, minimal diffs, and flat call hierarchies.

1|Updated Aug 26, 2026
One-click install
npx skills add https://github.com/edivad1999/stuc-stack --skill principle-laziness-protocol-edivad1999
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-laziness-protocol
Source: https://github.com/edivad1999/stuc-stack/tree/main/skills/principle-laziness-protocol
Command: npx skills add https://github.com/edivad1999/stuc-stack --skill principle-laziness-protocol-edivad1999

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI coding assistants tend to over-engineer solutions by adding unnecessary abstractions, layers, and boilerplate, producing code that is exhausting for humans to maintain. This Skill counteracts that bias by enforcing a laziness-first mindset during refactoring and code changes. ## Core Features & Use Cases - Deletion-first refactoring: Prioritizes removing code over adding new code when asked to improve or refactor. - Complexity guardrails: Keeps call hierarchies flat (no more than 3 files or layers to trace), consolidates repeated decisions behind a single source of truth, and minimizes diff size. - Signal threading checks: Stops and re-evaluates when a task requires passing a new signal through types, schemas, or pipelines, looking for a more direct path. - Use Case: When asked to add a configuration flag that would thread through five layers of an Android/Kotlin app, the Skill prompts you to find a simpler direct path or a single decision point instead. ## Quick Start Ask the AI to refactor this Kotlin module while applying the laziness protocol, preferring deletions and the smallest possible diff.

Frequently Asked Questions about principle-laziness-protocol

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I avoid over-engineering when refactoring code?▼

Prefer deletion over addition, keep the call hierarchy flat, and make the smallest change that solves the problem. If a human maintainer would find the result exhausting to maintain, the solution is too complex.

What is a flat call hierarchy in software design?▼

A flat call hierarchy avoids deep call chains so that answering a question about the code never requires tracing through more than 3 files or layers. A rich interface hiding substantial work does not count as a deep chain.

When should I question threading a signal through layers?▼

Stop and reconsider whenever a task asks you to pass a new signal through types, schemas, pipelines, or similar layers. Look for a more direct path or consolidate the decision behind one source of truth passed as a simple flag.

Does minimizing the diff mean avoiding all abstractions?▼

No. The protocol targets unnecessary abstractions and duplicated choices, not all structure. Consolidate repeated decisions into one source of truth and remove small pass-throughs and representation leaks before they compound.

When not to use a deletion-first refactoring approach?▼

Avoid it when the missing functionality is genuinely required and no existing code can be removed or consolidated. The protocol biases toward simplicity but does not replace implementing features the problem actually demands.