skills/thinking-feedback-loops/SKILL.md
Use when a system shows runaway growth/collapse, oscillates around a target, or resists change, and you need to find the loop driving it. Identifies reinforcing/balancing loops and delays.
npx skillsauth add tjboudreaux/cc-thinking-skills thinking-feedback-loopsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Feedback loop analysis (Donella Meadows, "Thinking in Systems") explains how a dynamic system behaves over time. Loops either amplify change (reinforcing) or stabilize toward a goal (balancing); delays between cause and effect produce oscillation. When a system grows uncontrollably, collapses, oscillates, or refuses to change, the loop structure is the cause.
Core Principle: System behavior emerges from feedback structure. To change behavior, change the loops.
When a system shows dynamic behavior (runaway growth, oscillation, resistance to change):
If there's no dynamic behavior (static, one-time cause), skip — just fix it. For overall system mapping, use thinking-systems. For choosing where to intervene in an already-mapped loop, use thinking-leverage-points.
System behavior is puzzling or problematic?
→ Is it growing/shrinking unexpectedly? → Look for REINFORCING LOOPS
→ Is it oscillating around a target? → Look for DELAYS in BALANCING LOOPS
→ Is it stuck/resistant to change? → Look for dominant BALANCING LOOPS
thinking-systems instead. Feedback loops zooms in on the specific dynamic loops driving behavior; systems maps the full territory first.thinking-leverage-points (Meadows' 12-level hierarchy). Feedback loops tells you which loop is dominant; leverage-points tells you where in that loop to act.Reinforcing loops amplify change in the same direction—growth or decline. They create exponential behavior: the more you have, the more you get (or lose).
Structure: A → increases B → increases A (or: A → decreases B → decreases A)
┌─────────────────────────────────────────────────────────┐
│ REINFORCING LOOP (R) │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Users │───(+)──▶│ Content │ │
│ └──────────┘ └────┬─────┘ │
│ ▲ │ │
│ │ (+) │
│ │ │ │
│ └────────────────────┘ │
│ │
│ More users → More content → More users (Growth) │
│ OR: Fewer users → Less content → Fewer users (Death) │
└─────────────────────────────────────────────────────────┘
Characteristics:
Software Examples:
Retry Storm Loop:
Service slow → Clients retry → More load → Service slower → More retries
(Vicious cycle toward outage)
Technical Debt Loop:
Shortcuts → Bugs → Firefighting → Less time → More shortcuts
(Vicious cycle toward collapse)
Cache Stampede Loop:
Cache miss → Backend load → Slower fills → More misses → More load
(Reinforcing under expiry)
Balancing loops counteract change, pushing the system toward a goal or equilibrium. They create goal-seeking behavior.
Structure: Gap between actual and goal → corrective action → reduces gap
┌─────────────────────────────────────────────────────────┐
│ BALANCING LOOP (B) │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Goal │ │ Actual │ │
│ │ State │ │ State │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ └──────────┬────────────────────┘ │
│ ▼ │
│ ┌──────────┐ │
│ │ Gap │ │
│ └────┬─────┘ │
│ │ │
│ (-) │
│ ▼ │
│ ┌────────────┐ │
│ │ Corrective │ │
│ │ Action │────────▶ Closes gap │
│ └────────────┘ │
└─────────────────────────────────────────────────────────┘
Characteristics:
Software Examples:
Auto-scaling Loop:
Load increases → Gap from target → Scale up → Load per instance decreases
(Goal: maintain target response time)
Backpressure Loop:
Queue depth rises → Producers throttled → Arrival rate drops → Queue drains
(Goal-seeking to bounded queue)
Circuit Breaker Loop:
Error rate exceeds threshold → Breaker opens → Load sheds → Service recovers
(Goal: maintain availability)
Delays are the time between cause and effect. They are the primary source of oscillation and instability in systems.
┌─────────────────────────────────────────────────────────┐
│ DELAY EFFECTS │
│ │
│ Action ───────[DELAY]─────────▶ Effect │
│ │
│ Short delay: System responds smoothly │
│ Long delay: Overshoot and oscillation │
│ │
│ Examples: │
│ • Code deploy → [Cache TTL] → Users see change │
│ • New hire → [Ramp-up time] → Productivity impact │
│ • Feature ship → [Adoption] → Metric movement │
│ • Training → [Skill development] → Performance gain │
└─────────────────────────────────────────────────────────┘
Why Delays Cause Oscillation:
Without delay:
Gap detected → Correction → Gap closes → Done
With delay:
Gap detected → Correction → [DELAY] → Gap persists →
More correction → [DELAY] → Original correction arrives →
Overshoot → Gap in opposite direction → Oscillation
Classic Example: Shower Temperature
Too cold → Turn hot → [Delay: water travels through pipes] →
Still cold → Turn hotter → Hot water arrives → Too hot! →
Turn cold → [Delay] → Still hot → Turn colder →
Cold water arrives → Too cold! → Oscillation continues
Structure: Single dominant reinforcing loop
┌─────────┐ ┌─────────┐
│ Revenue │─(+)─▶│ Invest- │
│ │ │ ment │
└────▲────┘ └────┬────┘
│ │
(+) (+)
│ │
└────────────────┘
Growth
Behavior: J-curve growth (or collapse if running in reverse)
Examples:
Intervention: Find or create balancing loops before runaway
Structure: Balancing loop with significant delay
┌────────┐ ┌────────┐
│ Goal │ │ Actual │
└───┬────┘ └───┬────┘
│ │
└───────┬───────┘
▼
[Gap]
│
(-)
│
▼
┌────────────┐
│ Correction │───[DELAY]───▶ Effect
└────────────┘
Behavior: Oscillation around goal, amplitude depends on delay length
Examples:
Intervention: Shorten delays, reduce correction magnitude, accept longer settling time
Structure: Reinforcing loop eventually hits a balancing constraint
┌─────────────────────────────────────┐
│ │
▼ │
┌────────┐ ┌─────┴────┐
│ Growth │──(+)──▶ Success ──(-)──▶│ Resource │
│ Effort │ │ Limit │
└────────┘ └──────────┘
│
└──(+)──▶ Results (initially)
Behavior: S-curve—growth, plateau, then stagnation or decline
Examples:
Intervention: Identify and address the constraint before hitting it
Structure: Symptomatic solution undermines fundamental solution
┌──────────────┐
│ Problem │
│ Symptom │
└──────┬───────┘
│
┌────────────┼────────────┐
▼ │ ▼
┌───────────┐ │ ┌───────────────┐
│ Quick │ │ │ Fundamental │
│ Fix │ │ │ Solution │
└─────┬─────┘ │ └───────┬───────┘
│ │ │
(+) │ (+)
│ │ │
▼ │ ▼
Symptom relief ────────┘ Root cause fixed
│ ▲
(-) │
▼ │
Motivation to ─────────────────────┘
fix root cause
Behavior: Addiction to quick fixes; fundamental capability atrophies
Examples:
Intervention: Deliberately invest in fundamental solution while managing symptoms
Structure: Two competing reinforcing loops
┌─────────┐ ┌─────────┐
│ Party A │──▶ │ Party B │
│ Action │ ▲ │ Action │
└────┬────┘ │ └────┬────┘
│ │ │
(+) │ (+)
│ │ │
└───────┴────────┘
Threat
Behavior: Mutual escalation until resource exhaustion or intervention
Examples:
Intervention: Break the loop through agreement, constraint, or reframing
List all relevant quantities that change over time:
Team productivity system:
- Team size
- Individual workload
- Code quality
- Technical debt
- Bug rate
- Firefighting time
- Feature velocity
- Morale
For each pair, ask: "Does A affect B? In which direction?"
(+) Same direction: A increases → B increases, A decreases → B decreases
(-) Opposite direction: A increases → B decreases
Follow the arrows back to starting point. Count the negative signs:
Even number of (-) = Reinforcing loop
Odd number of (-) = Balancing loop
The system behavior is driven by currently dominant loops:
Once you've found the dominant loop, intervene at the highest-leverage point you can move: changing a delay or a loop's gain beats tuning a parameter; changing a rule beats both. For Meadows' full 12-level hierarchy, see thinking-leverage-points—don't re-derive it here.
## Feedback Loop Analysis: [System Name]
### Current Behavior
[Describe: growing, declining, oscillating, stuck]
### Key Variables
- [List stocks and flows]
### Loop Diagram
[Draw or describe the loops]
### Identified Loops
| Loop Name | Type | Variables | Currently Dominant? |
|-----------|------|-----------|---------------------|
| | | | |
### Delays Present
| Delay | Duration | Effect |
|-------|----------|--------|
| | | |
### Leverage Points
| Level | Intervention | Expected Effect |
|-------|-------------|-----------------|
| | | |
### Recommended Intervention
[Highest-leverage, lowest-risk option]
thinking-systems: Map the overall system structure and trace cross-service causesthinking-feedback-loops: Identify and analyze the specific loop driving the dynamic behaviorthinking-leverage-points: Choose where to intervene (Meadows' 12-level hierarchy)"We can't control systems or figure them out. But we can dance with them."
"The least obvious part of the system, its function or purpose, is often the most crucial determinant of the system's behavior."
"Pay attention to what is important, not just what is quantifiable."
Systems are not puzzles to be solved but patterns to be understood and influenced. Effective intervention requires humility about control and attention to feedback.
tools
About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
development
Use when stuck between two architecture or API requirements that seem mutually exclusive — name the contradiction precisely, then separate the conflicting states in time, space, or condition.
testing
You need to trace how a system would fail or behave at a scale you can't cheaply test or measure. Use to imagine the scenario and walk the consequence chain step by step.
devops
Use when optimizing latency or throughput in a pipeline and one stage dominates—focus all effort on that single bottleneck, since speeding up the others changes nothing until it's fixed.