> reducing-entropy
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.
curl "https://skillshub.wtf/softaworks/agent-toolkit/reducing-entropy?format=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/
- 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.
> related_skills --same-repo
> writing-clearly-and-concisely
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
> web-to-markdown
Use ONLY when the user explicitly says: 'use the skill web-to-markdown ...' (or 'use a skill web-to-markdown ...'). Converts webpage URLs to clean Markdown by calling the local web2md CLI (Puppeteer + Readability), suitable for JS-rendered pages.
> skill-judge
Evaluate Agent Skill design quality against official specifications and best practices. Use when reviewing, auditing, or improving SKILL.md files and skill packages. Provides multi-dimensional scoring and actionable improvement suggestions.
> ship-learn-next
Transform learning content (like YouTube transcripts, articles, tutorials) into actionable implementation plans using the Ship-Learn-Next framework. Use when user wants to turn advice, lessons, or educational content into concrete action steps, reps, or a learning quest.