SystemsThinking

Customization

Before executing, check for user customizations at: ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/SystemsThinking/

If this directory exists, load and apply any PREFERENCES.md, configurations, or resources found there. These override default behavior. If the directory does not exist, proceed with skill defaults.

MANDATORY: Voice Notification (REQUIRED BEFORE ANY ACTION)

You MUST send this notification BEFORE doing anything else when this skill is invoked.

1. Send voice notification:

   bashCopy code
   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the SystemsThinking skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. Output text notification:

   Copy code
   Running the **WorkflowName** workflow in the **SystemsThinking** skill to ACTION...
   

This is not optional. Execute this curl command immediately upon skill invocation.

SystemsThinking Skill

What It Does

Analyzes complex systems to reveal why the same problem keeps coming back and where a small change produces a large result. Five workflows: Iceberg (walk symptom down to structure), CausalLoop (map feedback loops), FindArchetype (match a known pattern and apply its fix), FindLeverage (Meadows' 12 leverage points), ConceptMap (Novak entity-relationship). Grounded in Donella Meadows, Peter Senge, Jay Forrester, Russell Ackoff, and the Santa Fe Institute tradition.

The Problem

Most attempts to fix a recurring problem operate at the event layer — patch the bug, retry the request, add another check — and the problem comes back, because the real cause lives 3-4 layers below in the structure that generates the events. People also can't see second-order effects: a "fix" ships and creates a new problem, or makes the original worse. Without a way to see the structure, you treat symptoms forever and the obvious lever is almost never where the symptom shows up.

How It Works

Systems thinking is the difference between treating symptoms (patch the bug) and fixing structure (change the feedback loop that keeps producing the bug). The skill walks from visible events down to the structure underneath, names the pattern, and finds where to push.

The deliverable: identify the generating structure and the highest-leverage intervention, with second-order effects surfaced. A done analysis names the structure that produces the behavior (not the nearest event), the leverage point to push, and at least one round of the intervention's own feedback traced before shipping.

Core Concept

A system is a set of elements interconnected in a way that produces a characteristic behavior over time. Change the elements, often nothing happens. Change the interconnections or the purpose, and behavior shifts dramatically.

Five axioms this skill operates on:

1. Behavior is generated by structure. If the same outcome keeps happening, the cause is structural, not a series of unrelated incidents.
2. Events are visible; structure is not. Most analysis stops at events. Systems thinking walks down.
3. Feedback loops are the basic unit. Every persistent pattern is one of a small number of loop archetypes.
4. High-leverage interventions are usually counterintuitive. The obvious fix often makes the problem worse (policy resistance, shifting the burden, fixes that fail).
5. You can't optimize a part of a system — you can only improve the system. Local optimization often degrades global performance.

Use / Win

When to use:

• Recurring problems — the same kind of bug, incident, deadline slip, or conflict keeps appearing. Event-level fixes are not working.
• Unintended consequences — a "fix" produced a new problem, or made the original worse.
• System design — before committing to an architecture, product strategy, organization structure, or policy.
• Debugging systemic issues — distributed-system flakiness, performance cliffs, reliability decay, tech-debt accretion.
• Strategy — understanding where competition, demand, adoption, or resistance actually comes from.
• Policy, incentives, organization design — any environment where human behavior is an input.
• Before a large intervention — run the causal loop first; intended effects are rarely the only effects.

What you win:

• Structural causes instead of blame-the-nearest-event. The real lever is almost never where the symptom appeared.
• Archetype recognition — most organizational and technical pathologies match one of ~10 patterns. Naming the pattern unlocks the canonical intervention.
• Leverage-point identification — Meadows' 12 leverage points, ordered. Parameters are low leverage; paradigms are highest. Knowing where to push is the whole game.
• Unintended-consequence preview — causal loops let you simulate second- and third-order effects before shipping the change.
• Durable fixes — structural changes don't regress the way symptom patches do.

Default mental model: At Extended+ effort on anything with recurring behavior, organizational dynamics, or cross-component coupling, systems thinking is not optional enrichment — it's how you find the fix that sticks.

Workflow Routing

Route to the appropriate workflow based on the request.

Quick Reference

• 5 workflows — Iceberg, CausalLoop, FindArchetype, FindLeverage, ConceptMap
• Iceberg layers (top to bottom): Events → Patterns → Structures → Mental Models
• Feedback loop types: Reinforcing (R) — amplifying / exponential; Balancing (B) — goal-seeking / stabilizing
• Archetype count: ~10 canonical patterns (Senge, Braun)
• Leverage points: 12 levels, from parameters (weakest) to paradigm transcendence (strongest) — Meadows

Context files (loaded on demand):

• Foundation.md — Meadows, Senge, Forrester, Ackoff, Capra; canonical definitions
• Archetypes.md — the 10 systems archetypes with structure, recognition signs, canonical intervention
• LeveragePoints.md — Meadows' 12 leverage points with worked examples

Integration

Depends on: nothing — standalone analytical skill.

Works well with:

• RootCauseAnalysis — RCA is event-layer and pattern-layer; SystemsThinking continues down to structure and mental models. Pair them for deep incident analysis.
• FirstPrinciples — decompose to axioms, then use SystemsThinking to see how axioms interconnect.
• IterativeDepth — rotates lenses; SystemsThinking is the structural lens.
• BeCreative / Ideate — generate intervention candidates after identifying the leverage point.
• Art — render causal loop diagrams, iceberg diagrams, concept maps.

Examples

Example 1: Recurring incidents

Copy code
User: "we keep getting paged for the same class of timeout"
→ Iceberg workflow
→ Events: 6 pages in 3 weeks
→ Patterns: all during deploy windows, all touching payments service
→ Structure: auto-scaler cold-start latency > health-check timeout during deploys
→ Mental model: "deploys are safe if tests pass" — but health checks aren't in the test path
→ Fix is structural, not another retry

Example 2: Strategy

Copy code
User: "why does adding engineers slow us down past team size 12?"
→ FindArchetype workflow
→ Match: "Limits to Growth" archetype
→ Reinforcing loop: more engineers → more output → more hiring
→ Balancing loop: team size → coordination cost → per-engineer output ↓
→ Canonical intervention: attack the balancing loop (coordination mechanism), not the reinforcing one (stop hiring)

Example 3: Unintended consequences preview

Copy code
User: "we're about to add a rate limit to stop abuse"
→ CausalLoop workflow
→ Build CLD of users, abusers, support load, legitimate traffic
→ Surface: balancing loop (rate limit ↓ abuse), reinforcing loop (rate limit → legit users retry → total load ↑)
→ Recommend: rate-limit per-identity with reputation scoring, not per-IP

Gotchas

• Systems thinking is descriptive, not prescriptive. It reveals structure; it does not tell you what to build. Use it with BeCreative or FirstPrinciples to generate interventions.
• Don't mistake a list for a system. A system has feedback. If you can't draw at least one loop, you have a list of components, not a system.
• Blaming the model is the mistake. When a loop says something uncomfortable ("incentives are the cause"), the reaction is often to reject the model. Sit with it.
• Delay is underrated. Many systemic failures come from delays (between action and feedback). Capture delays explicitly on your diagram.
• Soft variables count. "Trust," "morale," "perceived safety" are as real as latency numbers in systems work. Don't drop them because they're hard to measure.

Attribution: Frameworks drawn from Donella Meadows (Thinking in Systems, 2008; "Places to Intervene in a System," 1999), Peter Senge (The Fifth Discipline, 1990), Jay Forrester (Industrial Dynamics, 1961), Russell Ackoff (Systems Thinking for Curious Managers), Fritjof Capra (The Web of Life), and the System Dynamics Society tradition.

Execution Log

After completing any workflow, append a single JSONL entry:

bashCopy code
echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"SystemsThinking","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl