principle-laziness-protocol

Featured

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.

Code & Development 333 stars 40 forks Updated 2 days ago MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
84
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
55
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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.

Details

Author
michael-denyer
Repository
michael-denyer/pstack-claude
Created
3 months ago
Last Updated
2 days ago
Language
TypeScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category