plugins/yzmir-systems-thinking/skills/using-systems-thinking/SKILL.md
Router for systems thinking methodology - patterns, leverage points, archetypes, stocks-flows, causal loops, BOT graphs
npx skillsauth add tachyon-beep/skillpacks using-systems-thinkingInstall 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.
Your entry point to systems thinking methodology. This skill routes you to the right combination of systems analysis skills for understanding complex, interconnected problems.
This is a meta-skill that:
You should use this skill: When facing complex problems with feedback loops, delays, unintended consequences, or persistent failures despite interventions.
IMPORTANT: All reference sheets are located in the SAME DIRECTORY as this SKILL.md file.
When this skill is loaded from:
skills/using-systems-thinking/SKILL.md
Reference sheets like causal-loop-diagramming.md are at:
skills/using-systems-thinking/causal-loop-diagramming.md
NOT at:
skills/causal-loop-diagramming.md ← WRONG PATH
When you see a link like [causal-loop-diagramming.md](causal-loop-diagramming.md), read the file from the same directory as this SKILL.md.
Linear Thinking: Problem → Solution → Fixed
Systems Thinking: Structure → Behavior → Intervention
✅ Use systems-thinking when:
❌ Don't use systems-thinking when:
When to use: ANY complex problem - start here Teaches: S-curves, feedback loops (reinforcing/balancing), delays, stock-flow thinking Examples: Viral growth, technical debt, burnout spirals Time: 45-60 min Key insight: Behavior patterns reveal underlying structure
When to use: Recognize recurring problem patterns Teaches: 10 classic archetypes (Fixes that Fail, Shifting the Burden, Escalation, etc.) Examples: Feature factory, hero culture, arms race Time: 60-90 min Key insight: Most problems match known patterns with known solutions
When to use: Design interventions, prioritize where to act Teaches: Donella Meadows' 12 leverage points hierarchy Examples: Constants (weak) vs rules vs paradigms (powerful) Time: 60-75 min Key insight: Small changes at high leverage points beat large changes at low points
When to use: Predict future states, calculate equilibrium, analyze accumulation dynamics Teaches: Formal notation, equilibrium analysis, time constants, delay analysis Examples: Customer churn, bug backlog, burnout accumulation Time: 75-90 min Key insight: Quantification elevates from "will get worse" to "6.7 weeks to crisis"
When to use: Map system structure, communicate feedback dynamics, find root causes Teaches: 6-step construction process, polarity testing, loop identification Examples: Death spirals, virtuous cycles, balancing processes Time: 60-75 min Key insight: Systematic construction prevents polarity errors that change diagnosis
When to use: Show trajectories, compare scenarios, communicate dynamics over time Teaches: 7-step construction, 70-80% scale rule, ASCII standards, validation Examples: S-curve adoption, crisis timing, intervention impact Time: 60-75 min Key insight: "What happens over time" with concrete numbers and dates
START: What's your goal?
├─ UNDERSTAND A PROBLEM (First time encountering complexity)
│ ├─ Start here → recognizing-system-patterns
│ ├─ Does it match a known pattern? → systems-archetypes-reference
│ └─ What behavior over time? → behavior-over-time-graphs
│
├─ MAP SYSTEM STRUCTURE (How does this work?)
│ ├─ Identify feedback loops → causal-loop-diagramming
│ ├─ Calculate accumulation → stocks-and-flows-modeling
│ └─ Show dynamics → behavior-over-time-graphs
│
├─ DESIGN INTERVENTIONS (What should we do?)
│ ├─ Identify leverage points → leverage-points-mastery
│ ├─ Predict outcomes → stocks-and-flows-modeling + behavior-over-time-graphs
│ └─ Match to archetype solution → systems-archetypes-reference
│
├─ COMMUNICATE TO STAKEHOLDERS (Convince others)
│ ├─ Executive version → behavior-over-time-graphs (with $ impacts)
│ ├─ Technical version → causal-loop-diagramming + stocks-and-flows-modeling
│ └─ Pattern recognition → systems-archetypes-reference ("We're in Fixes that Fail")
│
└─ QUANTITATIVE PREDICTION (When will crisis hit? How many?)
├─ Calculate trajectory → stocks-and-flows-modeling
├─ Visualize scenarios → behavior-over-time-graphs
└─ Validate structure → causal-loop-diagramming
Symptoms:
Routing Sequence:
Why this sequence:
Symptoms:
Routing Sequence:
Why this sequence:
Symptoms:
Routing Sequence:
Why this sequence:
Symptoms:
Routing Sequence:
Why this sequence:
Goal: Get buy-in for systems-based solution
Routing Sequence:
Why this sequence:
Symptoms:
Routing Sequence:
Why this sequence:
Process:
Total time: ~2.5-3 hours Output: Complete systems analysis with quantitative predictions and intervention design
Process:
Total time: ~35 min Output: Pattern diagnosis + known solution approach Trade-off: No quantification, no custom structure mapping
Process:
Total time: ~110 min Output: Executive presentation with quantified impact
Process:
Total time: ~4 hours Output: Comprehensive technical analysis with validated structure and quantified scenarios
Start here if new to systems thinking:
recognizing-system-patterns (REQUIRED FIRST)
systems-archetypes-reference (LEARN SECOND)
Choose path based on needs:
No prerequisites:
Requires recognizing-system-patterns:
Works better together:
| Rationalization | Reality | Counter-Guidance | Red Flag | |-----------------|---------|------------------|----------| | "Just add more resources" | Resource additions often activate balancing loops | "Route to leverage-points-mastery - this is lowest-leverage point (constants)" | Ignoring system structure | | "This isn't a system, it's a simple bug" | Bugs that persist are symptoms of system structure | "Route to systems-archetypes-reference - likely 'Fixes that Fail'" | Linear thinking on complex problems | | "We don't have time for analysis" | Crisis timing requires stock-flow calculation | "Route to stocks-and-flows-modeling - 15 min calculation vs wrong 6-month commitment" | Analysis paralysis fear | | "Our situation is unique" | 90% match archetypes | "Route to systems-archetypes-reference - most 'unique' problems aren't" | Not invented here syndrome | | "Just draw a quick diagram" | Polarity errors change diagnosis (R vs B) | "Route to causal-loop-diagramming - use systematic 6-step process" | Skipping validation | | "Intuition says it will get worse" | Intuition fails on delays, non-linear dynamics | "Route to stocks-and-flows-modeling - calculate, don't guess" | Overconfidence in intuition | | "We need to act NOW" | Acting without understanding wastes resources | "Route to recognizing-system-patterns - 15 min pattern ID prevents months of wrong solution" | Action bias | | "Too complicated to model" | Most systems can be modeled simply | "Route to stocks-and-flows-modeling - start with 1-2 stocks" | Complexity avoidance | | "Graphs are for presentations, not analysis" | Graphs reveal patterns invisible in tables | "Route to behavior-over-time-graphs - construction process IS analysis" | Separating analysis from communication |
Watch for these signs of incorrect approach:
If any red flag triggered → STOP → Route to appropriate skill(s)
Clarify boundaries with other approaches:
| Problem Type | Use Instead | Reason | |--------------|-------------|--------| | Well-understood algorithm optimization | Standard profiling/optimization | No feedback dynamics | | One-time decision with immediate result | Decision analysis, expected value | No time dynamics | | Pure data analysis / statistics | Data science methods | Not about system structure | | Legal/compliance requirements | Ordis security-architect | Different domain | | Pure UX research | Lyra ux-designer | Different methodology | | Code architecture | Axiom system-architect | Code structure, not system dynamics |
Edge case: Software architecture CAN have systems dynamics (technical debt accumulation, team coordination). Use both system-architect (structure) AND systems-thinking (dynamics).
First time with systems thinking? → recognizing-system-patterns (foundation skill, 45-60 min)
Problem keeps returning despite fixes? → systems-archetypes-reference → Find "Fixes that Fail" or "Shifting the Burden"
Need to predict future states? → stocks-and-flows-modeling → Calculate time to crisis, equilibrium
Need to map system structure? → causal-loop-diagramming → Visualize feedback loops
Need to design intervention? → leverage-points-mastery → Find high-leverage points
Need to communicate dynamics? → behavior-over-time-graphs → Show trajectories over time
Not sure where to start? → Use this router skill! Ask diagnostic questions:
Most common workflow: recognizing-system-patterns → systems-archetypes-reference → causal-loop-diagramming → stocks-and-flows-modeling → leverage-points-mastery → behavior-over-time-graphs
Time for complete analysis: 2.5-4 hours (depending on complexity)
Key principle: Start with patterns, match to archetypes, map structure, quantify dynamics, find leverage, visualize scenarios.
After routing, load the appropriate specialist skill for detailed guidance:
development
Use when **managing the delivery of work** rather than building it — running a project or a program, not writing its code. Use when a team is busy but outcomes are not landing, when "when will it be done" has no defensible answer, when status is green every week until it is suddenly red, when dependencies surprise you, when a RAID log is a graveyard, or when several projects must be coordinated toward one outcome (a program). Lean/agile-leaning, honest about where program scale needs predictive structure. Pairs with `/axiom-planning` (turning one workstream into an implementation plan) and `/axiom-sdlc-engineering` (process maturity, requirements traceability, formal governance). Do not load for writing code, picking an architecture, or designing a single feature.
tools
--- name: using-product-management description: Use when a Claude is taking **standing ownership** of a software product and driving it end-to-end across many sessions — discovery, strategy, specs, delivery orchestration, and value validation — deciding *what to build, why, for whom,* and *whether it worked*, with continuity, decision provenance, and an authority boundary that escalates anything irreversible or outward-facing to the human owner. Owns the product disciplines: opportunity assessme
tools
Use when designing, implementing, or auditing an MCP (Model Context Protocol) server — tool API design, idempotency under agent retry, structured error envelopes agents can recover from, schema versioning across model drift, transport reliability (stdio / HTTP), output-shape and pagination discipline, and choosing between tools / resources / prompts / sampling. Also use when an MCP server's tools confuse agents, return unstructured errors, deadlock under concurrent calls, double-execute under retry, or lose state across reconnects. Do not use for general REST/GraphQL API design (use `/web-backend`), for client-side prompt engineering or tool-loop design (use `/llm-specialist`), for general in-process plugin architecture (use `/system-architect`), or for cryptographic-provenance audit trails (use `/audit-pipelines`).
development
Use when running **SQLite or DuckDB inside an application process** as the durable store — not as a development convenience but as the production database. Use when scaling an SQLite layer that worked at low concurrency and is now hitting SQLITE_BUSY, WAL bloat, lock contention, schema-migration ceremony, or correctness gaps under multi-process writers. Use when introducing DuckDB as an OLAP complement to an OLTP SQLite store, or when picking between the two for a new component. Pairs with `/web-backend` (the API surface above the DB) and `/audit-pipelines` (when the DB is also the audit trail). Do not load for server databases (Postgres, MySQL), key-value stores, or ORM choice in isolation.