Catalog
softaworks/reducing-entropy

softaworks

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.

global
0installs0uses~628
v1.1Saved Apr 20, 2026

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.

Files7
7 files · 17.3 KB

Select a file to preview

Overall Score

82/100

Grade

B

Good

Safety

92

Quality

81

Clarity

85

Completeness

76

Summary

A manual-only skill for guiding agents to minimize total codebase size by measuring success through final code amount rather than effort. It provides a three-question framework for evaluating changes, requires loading a philosophical mindset before proceeding, and actively biases toward deletion over addition.

Detected Capabilities

Code size measurement and comparison (before/after line counts)Philosophy-guided design evaluation against multiple mindsetsAnti-pattern detection (status quo bias, YAGNI violations, over-separation)Codebase structure analysis (functions, files, dependencies)Trade-off reasoning (effort vs. end-state code metrics)

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

minimize codebase sizereduce technical debtsimplify architectureevaluate code costdelete instead of add

Risk Signals

INFO

Skill requires loading external mindset files before proceeding — potential for agent confusion if references/ directory is empty or inaccessible

SKILL.md: 'Do not proceed until you've done this'
WARNING

No guardrails documented for edge cases — skill provides philosophical framework but does not address scenarios where minimizing code conflicts with maintainability, readability, or safety requirements

SKILL.md: entire skill
WARNING

Skill explicitly rejects common software engineering concerns (type safety, separation of concerns, flexibility) without nuance — could lead to poor architectural decisions if applied to domains where these concerns are justified

SKILL.md: Red Flags section

Referenced Domains

External domains referenced in skill content, detected by static analysis.

curtclifton.netgithub.comgrugbrain.devjacobian.orglukeplant.me.ukpeps.python.orgsimonwillison.netwww.amazon.comwww.cs.unc.eduwww.dataorienteddesign.comwww.dreamsongs.comwww.infoq.comwww.youtube.com

Use Cases

  • Evaluate whether a feature request should be implemented based on code cost
  • Refactor existing code with a goal of reducing total lines/functions
  • Decide between multiple implementation approaches by final codebase size
  • Clean up technical debt while minimizing the final codebase
  • Assess whether a proposed abstraction or pattern adds or removes complexity

Quality Notes

  • Strong philosophical grounding: references directory provides four distinct, well-articulated mindsets with external citations and practical guidance
  • Clear success metrics defined: agent understands what 'done' looks like (fewer lines, fewer files, fewer functions)
  • Excellent anti-pattern detection: red flags table explicitly rejects common excuses for code growth, helping agents stay calibrated
  • Well-structured three-question framework: actionable, repeatable, measurable approach to evaluating changes
  • Good scope boundaries: explicitly states when skill does NOT apply (minimal codebases, strong framework conventions, regulatory requirements)
  • Comprehensive mindset infrastructure: adding-reference-mindsets.md provides clear standards for extending the knowledge base, with quality checklist and source material
  • Practical example included: usage example walks through how the three-question framework applies to real feature request
  • One limitation: skill is philosophy-heavy but lacks tactical guidance on *how* to discover what can be deleted (discovery process is assumed)
  • One limitation: no guidance on measuring code size (lines? AST nodes? cyclomatic complexity? function count?) — this is left implicit
  • Reference materials are authoritative and well-chosen: draws from Rich Hickey, Moseley & Marks, and other canonical sources on simplicity
Model: claude-haiku-4-5-20251001Analyzed: Apr 20, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

v1.1

Content updated

2026-04-20

Latest
v1.0

No changelog

2026-04-12

Add softaworks/reducing-entropy to your library

Command Palette

Search for a command to run...