reducing-entropy
Skill49 starsChanged 6 months agoMITView on GitHub
Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion.
7 other projects use a version of this, 7 of them edited.
Adopted by
Most recently taken up by
- ivanrvpereira/.agentsedited, first seen Nov 1, 2026
- imMamdouhaboammar/kaku-chatgpt-harnessedited, first seen Oct 25, 2026
- Samueladewole/claude-skillsedited, first seen Oct 13, 2026
- meshery/meshkitedited, first seen Oct 8, 2026
- meshery/mesheryedited, first seen Oct 8, 2026
- nbirkner/digital-brainedited, first seen Apr 12, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 7
- meshery/meshery★ 12k93% same
- meshery/meshkit★ 23393% same
- ivanrvpereira/.agents★ 1998% same
- wpank/ai★ 1121% same
- imMamdouhaboammar/kaku-chatgpt-harness★ 093% same
- nbirkner/digital-brain★ 089% same
- Samueladewole/claude-skills★ 093% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- coding-standardsSkill
- coolify-composeSkill
- crafting-effective-readmesSkill
- diataxisSkill
- english-pleaseSkill
- feature-planning-artifactsSkill
- frontend-design-principlesSkill
- grug-brained-devSkill
- html-artifactsSkill
- improveSkill
- improving-promptsSkill
- jjSkill
- researching-codebasesSkill
- roadmapSkill
- roadmap-to-improve-plansSkill
- rustSkill
- salsaSkill
- skill-authoringSkill
- strategic-roadmapSkill
- svelte5Skill
- sveltekitSkill
- writing-cli-skillsSkill
- writing-error-messagesSkill
- writing-plansSkill
- writingSkill
The file
We split this skill into the rules it gives an agent
2 rules. 2 are common, 0 are distinctive, and 0 are very specific to this project.
2
Common
Most of the 7 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 17
Read frontmatter descriptions to pick which applies
- Common: line 53
Every change is an opportunity to delete.
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

