Reducing Entropy
Explicitly invoke when you want an agent to shrink the codebase by deleting and consolidating instead of adding abstraction layers.
Overview
Reducing Entropy is an agent skill most often used in Ship (also Build, Operate) that minimizes final codebase size by deleting and consolidating—only when you explicitly request it.
Install
npx skills add https://github.com/softaworks/agent-toolkit --skill reducing-entropyWhat is this skill?
- Manual-only activation—never runs unless the user explicitly requests entropy reduction
- Forces loading at least one mindset reference from `references/` before any edits
- Success metric is final codebase size, not effort saved while writing
- Three-question framework: smallest solving codebase, net fewer lines, what gets deleted
- Explicit bias: writing 50 lines that delete 200 wins; keeping 14 functions to avoid writing 2 loses
- Three guiding questions before any change is accepted
- At least one mindset file from references/ must be loaded before proceeding
Adoption & trust: 3.7k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your repo keeps growing with “clean” refactors and optional features that nobody removes, and agents default to adding code instead of ending smaller.
Who is it for?
Solo builders doing intentional slim-down passes before a release, after a spike, or when retiring experiments.
Skip if: Sessions where the goal is new user-facing scope, exploratory prototypes you have not shipped yet, or when you forbid deletions without a separate product decision.
When should I use this skill?
User explicitly requests reducing entropy or minimizing total codebase size; never auto-activate.
What do I get? / Deliverables
After a session, accepted changes reduce net line count or remove whole features, with the agent documenting before/after counts and which reference mindset governed deletions.
- Before/after line-count assessment
- Deletion and consolidation patch with stated net LOC delta
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship review because the skill judges proposals by net line count after change—the same lens you use before merge or release—but it also applies mid-build refactors. Code review subphase fits the before/after line-count gate and rejection of “better organized” expansions.
Where it fits
Collapse fourteen helper functions into two after a spike once tests still pass.
Reject a PR that reorganizes packages but adds 400 lines without deleting dead exports.
Remove an unused feature flag path that still compiles but never runs in production.
How it compares
Use instead of open-ended “refactor for clarity” prompts that almost always add files and wrappers.
Common Questions / FAQ
Who is reducing-entropy for?
Maintainers of small codebases who want agents to act like ruthless editors—delete-first, count lines, and skip activation unless they name the skill.
When should I use reducing-entropy?
In Build when collapsing a module spike; in Ship review when a PR grows LOC without user value; in Operate when pruning dead paths—always by explicit user request, after loading a references mindset.
Is reducing-entropy safe to install?
It encourages deletions that can break callers; review the Security Audits panel on this page and run tests after any cut—the skill optimizes size, not backward compatibility by default.
SKILL.md
READMESKILL.md - Reducing Entropy
# 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.** --- description: 100 functions on one data structure beats 10 functions on 10 structures. Generic data and operations enable composition. --- # Data-Oriented Design ## The Core Principle > "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Generic operations on generic data structures beat specialized operations on specialized structures. ## Why Custom Abstractions Hurt Every custom type, wrapper class, or specialized structure: - Adds a concept to understand - Requires its own operations - Limits composition with other code - Creates maintenance burden A `Map<String, Value>` can be processed by hundreds of existing functions. A `SettingsManager` class can only be processed by the methods you write for it. ## Information Over Objects Model the information domain, not the behavior. - What data exists? - What are the essential relationships? - What transformations do you need? Then use generic structures (maps, vectors, sets) to represent that information. The behavior comes from functions that operate on data - not from methods bound to custom objects. ## Practical Application Before creating a new class/type, ask: - Could this be a map/dict with well-known keys? - Could this be a simple tuple/record? - Do I need custom behavior, or just data? If you just need data, use data structures. Save custom types for when you genuinely need custom behavior t