Reducing Entropy

by softaworks3027f20f3181No license2.5K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 7 months ago

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.

AI-generated overview

Guides an agent to minimize total codebase size by biasing toward deletion and measuring the final code amount.

What it does
Provides a manual-only decision framework for reducing total codebase size, centered on three questions about the smallest possible result, whether a change reduces total code, and what can be deleted. It lists red flags such as status-quo bias and added flexibility, and notes cases where the approach does not apply. It also directs the agent to load at least one philosophical mindset from its references directory before proceeding.
When to use it
Use when a user explicitly requests codebase size reduction or deletion-oriented refactoring. It is not meant to activate automatically, and it is unsuitable for already-minimal codebases, strongly conventional frameworks, or structures required by regulation or compliance.
Requirements
No scripts or tools; it is instructions only. The agent must be able to read the bundled reference markdown files, including the references directory and adding-reference-mindsets.md.

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/

  1. List the files in the reference directory
  2. Read frontmatter descriptions to pick which applies
  3. Load at least one
  4. 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.

Source and attribution

Source:softaworks/agent-toolkitinskills/reducing-entropyat commit3027f20

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal