Skill

Pass

Audit score 90

reducing-entropy

softaworks/agent-toolkit

Minimize total codebase size by biasing toward deletion and measuring final code amount.

What is reducing-entropy?

A manual-only skill for reducing code entropy by focusing on the smallest possible final codebase rather than minimizing effort. Activate only when explicitly requested, and measure success by total lines of code remaining, not by the effort to get there.

Evaluates whether proposed changes result in net reduction of total codebase lines
Identifies code that becomes obsolete when implementing new solutions
Challenges status quo bias and flexibility arguments that add code without proportional benefit
Applies philosophical mindsets from references to guide deletion-first decision making
Compares before/after code metrics to ensure changes reduce entropy

How to install reducing-entropy

npx skills add https://github.com/softaworks/agent-toolkit --skill reducing-entropy

Prerequisites

Load at least one mindset from the references/ directory before proceeding
Understand the core principle of the selected mindset

Claude Code

Cursor

Windsurf

Cline

How to use reducing-entropy

1.Load a mindset from references/ and state which one and its core principle
2.Ask: What is the smallest codebase that solves this problem?
3.Count total lines of code before and after the proposed change
4.Reject changes where final code amount exceeds starting code amount
5.Identify what code becomes obsolete and can be deleted
6.Measure the end state, not the effort required

Use cases

Good for

Refactoring a feature-heavy codebase to remove unused or redundant functionality
Evaluating whether to add a new abstraction or delete existing code instead
Deciding between multiple implementation approaches by measuring final codebase size
Cleaning up legacy code by identifying what can be eliminated entirely
Assessing framework upgrades or architectural changes for net code reduction

Who it's for

Developers working on legacy or bloated codebases
Teams prioritizing maintainability through code minimization
Architects evaluating architectural changes by code footprint
Anyone explicitly requesting entropy reduction in their codebase

reducing-entropy FAQ

When should I use this skill?

Only when explicitly requested by the user. This skill is manual-only and should not be activated automatically.

How do I measure success?

By final code amount remaining, not by effort expended. A change that writes 50 lines but deletes 200 lines is a success; keeping 14 functions to avoid writing 2 is a failure.

What if adding code improves organization or flexibility?

Those are not goals. If the change results in more total code, it increases entropy and should be rejected. Better organization with more code is still more entropy.

What are red flags to watch for?

Status quo bias ('keep what exists'), flexibility arguments ('this adds flexibility'), separation of concerns that adds code, type safety overhead, and readability claims that justify more code.

When does this skill not apply?

When the codebase is already minimal for what it does, when you're in a framework with strong conventions, or when regulatory/compliance requirements mandate certain structures.

Full instructions (SKILL.md)

Source of truth, from softaworks/agent-toolkit.

name: reducing-entropy description: 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.

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.