Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-leverage-points
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-leverage-points.SKILL.md
---name: thinking-leverage-points
description: Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
---# Leverage Points
## Overview
Donella Meadows' "Places to Intervene in a System" ranks intervention points by their power to change behavior. Most effort goes into low-leverage moves (parameters, buffers) when higher-leverage points (rules, goals, structure) change behavior with less force. This is the canonical home of the 12-level hierarchy—other skills (`thinking-systems`, `thinking-feedback-loops`) reference it instead of duplicating it.
**Core Principle:** Higher in the hierarchy = more leverage, but more resistance. Find the highest leverage point you can actually move.
## When to Use
- Choosing where to focus engineering effort on a system you can already see
- Incremental tweaks (timeouts, buffer sizes, more instances) keep not solving the problem
- Deciding between a quick parameter change and a structural fix
```
Want to change system behavior?
→ Stuck tuning parameters with no lasting effect? → MOVE UP THE HIERARCHY
→ Found the lever but the change won't stick? → look for a balancing loop resisting it
```
## When NOT to Use
- You haven't yet located the cause or mapped the system → use `thinking-systems` first; you can't rank interventions on a system you don't understand.
- A single low-level parameter genuinely is the fix (e.g., a wrong timeout value) → just change it; don't manufacture a paradigm shift.
- The decision is a one-off with no system behind it → this hierarchy adds nothing.
## Trigger Card
When tuning parameters keeps not sticking and you need to pick where to intervene:
1. **Identify the system goal** — what is the system trying to do? This is the highest-leverage point.
2. **Scan the hierarchy top-down** — from goals/rules/power down to parameters. Don't start at the bottom.
3. **Intervene at the highest feasible point** — pick the highest-leverage point you can actually change, not the easiest.
If a single low-level parameter genuinely is the fix (wrong timeout value), just change it. If there's no system behind the decision, skip — this hierarchy adds nothing.
## The 12 Leverage Points (Low to High)
### Level 12: Constants and Parameters (LOWEST LEVERAGE)
- Surfacing a previously-hidden metric (queue depth, error budget, p99)
- Logging the value that was silently defaulting
- Making a failure mode observable instead of swallowed
**Why high leverage:** A component can only respond to what it can see. Adding a feedback signal where one was missing changes behavior without changing any logic.
```
Intervention: Emit and alert on cache hit-rate that was previously invisible
Result: Regression caught immediately instead of after an outage
Leverage: High—behavior change through visibility
```
### Level 5: System Rules
**What:** Constraints the system enforces—what's allowed, required, or rejected
**Examples:**
- A required CI gate / merge check
- A schema or contract that rejects invalid input at the boundary
- A deployment policy (canary, required rollback path)
- A rate limit or quota
**Why high leverage:** Rules define what's even possible. Change the rule and a whole class of behavior changes or becomes impossible.
```
Intervention: Make the type checker / schema validation a hard CI gate
Result: An entire class of bug can no longer reach production
Leverage: High—changes what's acceptable
```
### Level 4: Self-Organization
**What:** Ability of the system to change its own structure
**Examples:**
- Plugin/extension points instead of hardcoded behavior
- Services that can register/discover each other dynamically
- Auto-scaling and self-healing instead of fixed topology
- Schema/config that the system can evolve safely
**Why very high leverage:** Systems that can adapt their own structure survive change; rigid systems eventually break.
```
Intervention: Replace a hardcoded dispatch table with a plugin registry
Result: New behavior added without touching the core; the system evolves
Leverage: Very high—enables adaptation
```
### Level 3: System Goals
**What:** What the system is actually optimizing for
**Examples:**
- The objective a scheduler/optimizer maximizes
- The SLO the system is built to hold
- The success metric a pipeline is tuned against
**Why very high leverage:** Everything downstream serves the goal. Optimizing for the wrong target reliably produces the wrong behavior, no matter how good the parts are.
```
Intervention: Change a cache eviction goal from "max hit rate" to "bound tail latency"
Result: Different eviction policy, different downstream behavior entirely
Leverage: Very high—redirects all effort
```
### Level 2: Paradigm (Mindset)
**What:** The shared assumptions from which goals and architecture arise
**Examples:**
- "Cache everything" vs "Cache only what's measured hot"
- "Microservices always" vs "Right tool for context"
- "Avoid failure" vs "Design for graceful degradation"
**Why transformational:** Paradigms are upstream of goals, rules, and structure. Shift the paradigm, transform the system.
```
Intervention: Shift from "retry until success" to "fail fast + shed load"
Result: Retry storms become impossible; the whole failure mode changes
| Retry storms under load | Lower retry count (12) | Change the retry paradigm: fail fast + shed (2) |
| Same bug class recurs | Patch each instance (12) | Make it unrepresentable via type/schema (10, 4) |
| Hidden, wrong defaults | Tune the value (12) | Make the config visible/validated (6, 5) |
## Verification Checklist
- [ ] Identified current intervention points
- [ ] Mapped interventions to leverage hierarchy
- [ ] Asked "what's the higher-leverage version?" for each
- [ ] Assessed feasibility vs. leverage tradeoff
- [ ] Selected highest feasible leverage point
- [ ] Considered resistance and how to address it
- [ ] Have strategy for paradigm-level resistance if applicable
## Key Questions
- "What level of leverage am I operating at?"
- "What's one level higher I could try?"
- "Why hasn't this parameter tuning fixed the problem?"
- "What information is missing that would change behavior?"
- "What rule change would make this unnecessary?"
- "What goal are we actually optimizing for?"
- "What paradigm is constraining our thinking?"
## Meadows' Wisdom
"People who manage to intervene in systems at the level of paradigm hit a leverage point that totally transforms systems."
"Magical leverage points are not easily accessible, even if we know where they are. There are no cheap tickets to mastery."
The highest leverage requires the most skill and often the most patience. But knowing where leverage exists helps you stop wasting effort at the bottom of the hierarchy.
