reducing-entropy
The reducing-entropy skill minimizes total codebase size by systematically identifying and removing unnecessary code, prioritizing the final code amount over implementation effort. Activate this skill only when a user explicitly requests code reduction, refactoring toward simplicity, or entropy minimization, and always begin by loading a relevant mindset from the references directory to ground the approach.
git clone --depth 1 https://github.com/softaworks/agent-toolkit /tmp/reducing-entropy && cp -r /tmp/reducing-entropy/dist/plugins/reducing-entropy/skills/reducing-entropy ~/.claude/skills/reducing-entropySKILL.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/`** 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.**
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
Use this agent when you need to visualize UI concepts through ASCII mockups before implementation. Examples: <example>Context: User has an idea for a dashboard layout with data tables and charts. user: 'I want to create a dashboard that shows user analytics with a sidebar navigation, main content area with charts, and a data table below' assistant: 'I'll use the ascii-ui-mockup-generator agent to create multiple ASCII mockup variations for your dashboard concept.' <commentary>The user wants to visualize a UI concept, so use the ascii-ui-mockup-generator to create multiple ASCII representations they can choose from.</commentary></example> <example>Context: User is designing a form layout with multiple input fields. user: 'I need a contact form with name, email, message fields and a submit button' assistant: 'Let me use the ascii-ui-mockup-generator to create several ASCII mockup options for your contact form layout.' <commentary>Since the user needs to visualize form layouts, use the ascii-ui-mockup-generator to provide multiple ASCII design options.</commentary></example>
Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'frontend handoff', or 'API documentation'.
Generate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, create C4 diagrams, or generate context/container/component/deployment diagrams. Triggers include "architecture diagram", "C4 diagram", "system context", "container diagram", "component diagram", "deployment diagram", "document architecture", "visualize architecture".
codebase-pattern-finder is a useful subagent_type for finding similar implementations, usage examples, or existing patterns that can be modeled after. It will give you concrete code examples based on what you're looking for! It's sorta like codebase-locator, but it will not only tell you the location of files, it will also give you code details!
Use when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing. Uses GPT-5.2 by default for state-of-the-art software engineering.
Create a detailed implementation plan using Codex 5.2 with high reasoning
This skill should be used when creating a Claude Code slash command. Use when users ask to "create a command", "make a slash command", "add a command", or want to document a workflow as a reusable command. Essential for creating optimized, agent-executable slash commands with proper structure and best practices.