home / skills / yousufjoyian / claude-skills / simplification-cascades
This skill helps you identify a single insight that eliminates multiple components by exposing a unifying abstraction across systems.
npx playbooks add skill yousufjoyian/claude-skills --skill simplification-cascadesReview the files below or copy the command above to add this skill to your agents.
---
name: simplification-cascades
description: Find one insight that eliminates multiple components - "if this is true, we don't need X, Y, or Z"
---
# Simplification Cascades
## Overview
Sometimes one insight eliminates 10 things. Look for the unifying principle that makes multiple components unnecessary.
**Core principle:** "Everything is a special case of..." collapses complexity dramatically.
## Quick Reference
| Symptom | Likely Cascade |
|---------|----------------|
| Same thing implemented 5+ ways | Abstract the common pattern |
| Growing special case list | Find the general case |
| Complex rules with exceptions | Find the rule that has no exceptions |
| Excessive config options | Find defaults that work for 95% |
## The Pattern
**Look for:**
- Multiple implementations of similar concepts
- Special case handling everywhere
- "We need to handle A, B, C, D differently..."
- Complex rules with many exceptions
**Ask:** "What if they're all the same thing underneath?"
## Examples
### Cascade 1: Stream Abstraction
**Before:** Separate handlers for batch/real-time/file/network data
**Insight:** "All inputs are streams - just different sources"
**After:** One stream processor, multiple stream sources
**Eliminated:** 4 separate implementations
### Cascade 2: Resource Governance
**Before:** Session tracking, rate limiting, file validation, connection pooling (all separate)
**Insight:** "All are per-entity resource limits"
**After:** One ResourceGovernor with 4 resource types
**Eliminated:** 4 custom enforcement systems
### Cascade 3: Immutability
**Before:** Defensive copying, locking, cache invalidation, temporal coupling
**Insight:** "Treat everything as immutable data + transformations"
**After:** Functional programming patterns
**Eliminated:** Entire classes of synchronization problems
## Process
1. **List the variations** - What's implemented multiple ways?
2. **Find the essence** - What's the same underneath?
3. **Extract abstraction** - What's the domain-independent pattern?
4. **Test it** - Do all cases fit cleanly?
5. **Measure cascade** - How many things become unnecessary?
## Red Flags You're Missing a Cascade
- "We just need to add one more case..." (repeating forever)
- "These are all similar but different" (maybe they're the same?)
- Refactoring feels like whack-a-mole (fix one, break another)
- Growing configuration file
- "Don't touch that, it's complicated" (complexity hiding pattern)
## Remember
- Simplification cascades = 10x wins, not 10% improvements
- One powerful abstraction > ten clever hacks
- The pattern is usually already there, just needs recognition
- Measure in "how many things can we delete?"
This skill helps you find a single insight that eliminates multiple components or workstreams by exposing the unifying principle behind them. It teaches a pattern-oriented approach to collapse duplicated implementations, special cases, and layered rules into a single, maintainable abstraction. Use it to drive high-leverage refactors that remove complexity rather than redistribute it.
The skill inspects code, config, and design notes to list repeated variations and special-case logic. It guides you to identify the shared essence, propose a domain-independent abstraction, and validate that abstraction against all cases. Finally, it estimates the cascade effect by counting how many components, handlers, or rules can be removed or simplified.
How do I know a cascade is safe?
Validate the abstraction against all current cases, write tests for edge behaviors, and confirm no hidden invariants are lost before deleting components.
What if some cases truly differ?
Keep a small extension point: implement the general case and allow targeted overrides only when a case cannot be expressed by the abstraction.