reducing-entropy
An optimization tool focused on reducing total lines of code through strategic deletion.
Install
mkdir -p .claude/skills/reducing-entropy && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/754" && unzip -o skill.zip -d .claude/skills/reducing-entropy && rm skill.zipInstalls to .claude/skills/reducing-entropy
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Manual-only skill for minimizing total codebase size. Only activate when explicitly requested by user. Measures success by final code amount, not effort. Bias toward deletion.Key capabilities
- →Identify opportunities to reduce total line count
- →Remove obsolete or redundant code functions
- →Refactor code for minimal footprint
- →Measure codebase size before and after changes
How it works
The agent evaluates the codebase to identify redundant logic and prioritizes deletion to achieve the smallest possible final codebase size.
Inputs & outputs
When to use reducing-entropy
- →Reduce codebase size
- →Remove redundant functions
- →Refactor for minimal footprint
About this skill
Reducing Entropy
More code begets more code. Entropy accumulates. This skill biases toward the smallest possible codebase.
Core question: "What does the codebase look like after?"
Before You Begin
Load at least one mindset from references/
- List the files in the reference directory
- Read frontmatter descriptions to pick which applies
- Load at least one
- State which you loaded and its core principle
Do not proceed until you've done this.
The Goal
The goal is less total code in the final codebase - not less code to write right now.
- Writing 50 lines that delete 200 lines = net win
- Keeping 14 functions to avoid writing 2 = net loss
- "No churn" is not a goal. Less code is the goal.
Measure the end state, not the effort.
Three Questions
1. What's the smallest codebase that solves this?
Not "what's the smallest change" - what's the smallest result.
- Could this be 2 functions instead of 14?
- Could this be 0 functions (delete the feature)?
- What would we delete if we did this?
2. Does the proposed change result in less total code?
Count lines before and after. If after > before, reject it.
- "Better organized" but more code = more entropy
- "More flexible" but more code = more entropy
- "Cleaner separation" but more code = more entropy
3. What can we delete?
Every change is an opportunity to delete. Ask:
- What does this make obsolete?
- What was only needed because of what we're replacing?
- What's the maximum we could remove?
Red Flags
- "Keep what exists" - Status quo bias. The question is total code, not churn.
- "This adds flexibility" - Flexibility for what? YAGNI.
- "Better separation of concerns" - More files/functions = more code. Separation isn't free.
- "Type safety" - Worth how many lines? Sometimes runtime checks in less code wins.
- "Easier to understand" - 14 things are not easier than 2 things.
When This Doesn't Apply
- The codebase is already minimal for what it does
- You're in a framework with strong conventions (don't fight it)
- Regulatory/compliance requirements mandate certain structures
Reference Mindsets
See references/ for philosophical grounding.
To add new mindsets, see adding-reference-mindsets.md.
Bias toward deletion. Measure the end state.
When not to use it
- →When the codebase is already minimal
- →When working within strict framework conventions
- →When regulatory requirements mandate specific structures
Prerequisites
Limitations
- →Only activates when explicitly requested
- →Rejects changes that increase total line count
How it compares
It focuses exclusively on minimizing the final code volume rather than improving organization or adding features.
Compared to similar skills
reducing-entropy side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| reducing-entropy (this skill) | 3 | 6mo | No flags | Intermediate |
| effective-go | 323 | 9mo | No flags | Beginner |
| solid-principles | 57 | 9mo | No flags | Intermediate |
| typescript-review | 39 | 2mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by davila7
View all by davila7 →You might also like
effective-go
openshift
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.
solid-principles
SmidigStorm
Enforce SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) in object-oriented design. Use when writing or reviewing classes and modules.
typescript-review
metabase
Review TypeScript and JavaScript code changes for compliance with Metabase coding standards, style violations, and code quality issues. Use when reviewing pull requests or diffs containing TypeScript/JavaScript code.
ast-grep
ast-grep
Guide for writing ast-grep rules to perform structural code search and analysis. Use when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search. This skill should be used when users ask to search for code patterns, find specific language constructs, or locate code with particular structural characteristics.
serena
massgen
This skill provides symbol-level code understanding and navigation using Language Server Protocol (LSP). Enables IDE-like capabilities for finding symbols, tracking references, and making precise code edits at the symbol level.
typescript
lobehub
TypeScript code style and optimization guidelines. Use when writing TypeScript code (.ts, .tsx, .mts files), reviewing code quality, or implementing type-safe patterns. Triggers on TypeScript development, type safety questions, or code style discussions.