principle-laziness-protocol

Guides refactoring decisions toward deletion and minimal diffs over added abstractions.

2|Updated Jun 27, 2026

Search Tags:#code review #refactoring #abstraction #minimal diff #deletion #code simplification #call hierarchy

One-click install

npx skills add https://github.com/imjasonh/playground --skill principle-laziness-protocol-imjasonh

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: principle-laziness-protocol
Source: https://github.com/imjasonh/playground/tree/main/.cursor/skills/principle-laziness-protocol
Command: npx skills add https://github.com/imjasonh/playground --skill principle-laziness-protocol-imjasonh

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate unnecessary abstractions, deep call chains, and duplicated decisions that make maintenance exhausting. This Skill provides a decision protocol that biases code changes toward deletion and the smallest possible diff. ## Core Features & Use Cases - Deletion-First Refactoring: Prioritizes removing code over adding new layers when improving existing code. - Flat Call Hierarchy Enforcement: Flags designs where answering a question requires tracing through more than 3 files or layers. - Decision Consolidation: Identifies repeated choices and moves them behind a single source of truth passed as a simple flag. - Use Case: When asked to thread a new signal through types, schemas, and pipelines, apply this protocol to stop and find a more direct path instead of propagating the change across layers. ## Quick Start Apply the laziness protocol to review this refactoring plan and reduce it to the smallest change that solves the problem.

Frequently Asked Questions about principle-laziness-protocol

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

FAQPage Schema

How do I reduce diff size when refactoring code?▼

Look for deletions before additions and make the smallest change that solves the problem. Fewer lines beat elegant boilerplate, and repeated decisions should be consolidated behind one source of truth passed as a simple flag.

When should I avoid adding abstraction layers?▼

Avoid new layers when a task asks you to thread a signal through types, schemas, or pipelines. Stop and look for a more direct path, since pass-throughs and representation leaks compound into permanent coordination costs.

What is a flat call hierarchy in software design?▼

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

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

Deletion-first thinking is a bias, not a ban on additions. It fits refactoring and improvement tasks, but genuinely new features or missing capabilities still require new code when no existing code can be removed or simplified.