A manual-only skill that minimizes total codebase size by biasing toward deletion and measuring success by the final amount of code rather than the effort of the change. It evaluates refactoring or new features based on whether they reduce the overall line count and complexity.
Quality gate: FAIL · better answers · measured 2026-10-24 Blind-judged against the bare model on 2 requests: average lift -7.0 points (specificity, structure, method, fit). won 0/2, lift -7.0, tokens ×907.54
Security scan: clean · 2026-10-24 · 7 files · ran in sandbox no network calls, shell tricks, credential access or instruction tampering found in its files.
Try asking
Say it in your own words; the assistant finds this recipe by itself. Examples:
“Jeg vil gerne minimere størrelsen på denne fil. Hvad kan jeg slette for at få færre linjer i alt?”
“Refaktorér denne modul. Målet er den mindst mulige mængde kode til sidst, uanset hvor meget jeg skal skrive undervejs.”
“Denne funktion er for kompleks. Kan du fjerne de fleksible indstillinger, vi ikke bruger, for at gøre den kortere?”
“I want to shrink this module. Look at the code and tell me what I can delete to make it smaller.”
“Refactor this utility file. The goal is to have the fewest possible lines of code at the end, even if I have to rewrite parts of it.”
“This feature is bloated. Can you simplify it by removing the flexible options we don't actually use?”
Try this skill from Claude, ChatGPT or a chat on your own page. Free plan, no credit card.Get started free
Do not use this skill for standard refactoring where readability or separation of concerns is prioritized over line count, as it may suggest harmful deletions. It is not for adding features that inherently require more code without a corresponding large deletion elsewhere. Avoid using it when compliance or framework conventions mandate specific structural patterns that cannot be simplified.
Details
When it is the right choice
Use this skill when the user explicitly requests to reduce code size, simplify the codebase, or minimize entropy. It is appropriate when the goal is to delete obsolete code, consolidate functions, or ensure that any new code results in a net reduction of total lines. It applies to refactoring tasks where the primary metric is the final state's brevity.
The full recipe the assistant reads
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.
Files in this skill (8)
LICENSE
README.md
SKILL.md
adding-reference-mindsets.md
references/data-over-abstractions.md
references/design-is-taking-apart.md
references/expensive-to-add-later.md
references/simplicity-vs-easy.md
Where it comes from
Vendored from softaworks/agent-toolkit, commit 3027f20f3181, path skills/reducing-entropy, licence MIT. The upstream licence file ships inside the skill.