systems-thinking

name	systems-thinking
description	Apply systems thinking to a problem, decision, or situation. Classifies the problem as a clear, complicated, complex, or chaotic system, diagnoses it with the DART framework (Deconstruct, Analyze, Recognize, Test), surfaces hidden parts/connections/patterns and traps (incentive/cobra effects, delayed feedback loops), and recommends the action protocol that fits the system type. Use when asked to "apply systems thinking", "think in systems", "what kind of problem is this", "how should I approach this", "analyze this decision/situation", "should I X or Y", or when facing a messy call where the right approach is unclear. Do NOT use for routine tasks that already have an obvious, agreed solution.
user-invocable	true
argument-hint	<problem, decision, or situation to analyze>

Systems Thinking

Read a situation before acting on it. A system is a set of connected parts that keep producing a pattern — a company, a career, a marriage, a coffee shop. Most expensive mistakes come from acting on the visible parts while holding the wrong model of the pattern. This skill runs a given prompt through a diagnostic that names the system, classifies its type, and matches the right protocol — because bringing the right approach to the wrong kind of system is itself the error.

The four-type model below is the Cynefin framework (Dave Snowden). The DART diagnostic and the "platform" tools are the framing from the source talk.

What this skill produces

Given a problem/decision/situation, output a structured diagnosis: the system and its pattern → DART analysis → system type → traps present → the matched action protocol → how to verify you read it right. Fill the output template.

For deep type cards, signals, and a worked example, read references/systems-field-guide.md when a classification is non-obvious.

Step 1 — Frame the system

State the system in one line, then move parts → connections → pattern. Probe what is not visible with three questions:

• Hidden parts — which actors, incentives, constraints, or resources aren't named in the prompt?
• Connections — what flows between the parts (information, money, approval, trust, order-of-operations)?
• Pattern — what outcome does this configuration keep producing, regardless of intent?

Step 2 — Diagnose with DART

Step	Question	What it tells you
D — Deconstruct	Break the problem into sub-parts. Are the parts stable or constantly shifting?	Stable → leans clear/complicated. Shifting → leans complex/chaotic.
A — Analyze	(decisive) What is the relationship between cause and effect?	Maps directly to the system type (Step 3).
R — Recognize	Have I seen this pattern before — here or in a structurally similar system?	Borrows a tested response; guards against treating the familiar as novel.
T — Test	What is the smallest reversible test before committing to a full response?	De-risks the move. Exception: chaotic systems leave no time to test.

Step 3 — Classify the system type

The Analyze answer picks the type. Each type has one correct posture; using another type's protocol is the classic failure.

System	Cause ↔ effect	Tell	Protocol
Clear	Obvious, directly observable	Competent people agree on the steps; best practice exists; repeatable	Follow the stable process. Use a checklist. Don't improvise. Watch for your "brown M&M" — the small tell that the process was skipped.
Complicated	Exists but hidden; needs analysis	A knowable right answer exists but isn't obvious; solvable by the right pro	Slow down, analyze, hire the right specialist — not just any expert (a cardiac surgeon won't treat lung cancer).
Complex	Visible only in hindsight	Experts disagree; the same action gives different results; people/culture/adaptation involved	Run small, safe-to-fail experiments; amplify what works, dampen what doesn't; course-correct. Aim to be directionally right, not precisely right.
Chaotic	Link is broken; info incomplete and shifting	Novel crisis, safety at stake, no time, ground still moving	Act first — stabilize, create safety, then understand. Avoid analysis paralysis. Once stable it usually becomes complex/complicated.

Layered systems are common. Many real problems stack types — e.g., building an AI rollout is complicated (hire experts, build a roadmap), but getting people to adopt it is complex (outcome emerges over time). Classify each layer and apply its own protocol.

Step 4 — Check the three traps

These distort the diagnosis or sabotage the action. Flag any that are present:

• Wrong-type approach — applying one type's protocol to another (a checklist for a teenager; running experiments during an earthquake). State the protocol the prompt is implicitly assuming and whether it fits.
• Incentive / cobra effect — a reward attached to a proxy makes people optimize the proxy and abandon the goal (a bounty on dead cobras bred more cobras). Ask: what does this system actually reward, and how will people game it?
• Delayed feedback — consequences surface long after the action (cigarettes: relief in seconds, damage in decades). Ask: what is the lag between action and signal? Don't read early quiet as success.

Step 5 — Apply the matched protocol

Translate the Step 3 protocol into concrete next actions for this specific prompt — name the checklist, the specialist to call, the experiment to run, or the stabilizing move. Be specific, not generic.

Step 6 — Verify direction (get on the platform)

From inside a system you can't tell which way it's carrying you (the moving-train illusion). Recommend at least one outside vantage point to confirm the read:

• Mentor — someone outside the situation with no stake in the story.
• Data — what the system actually does vs. what you believe it does.
• Time — compare against a week / month / year ago.

Step 7 — Binary check (when the prompt is "X or Y")

Most either/or framings are limits of the current system design, not limits of reality (Ferrari vs. Toyota → Apple ships a luxury product at mass-market scale). If the prompt forces a binary, test whether a redesign dissolves it — including the story the asker tells about what they're capable of.

Output template

## System
<one-line name> — the pattern it keeps producing: <pattern>

## Parts → Connections → Pattern
- Parts: ...
- Connections: ...
- Hidden / easily missed: ...

## DART
- Deconstruct: parts are <stable | shifting>
- Analyze: cause→effect is <obvious | discoverable | hindsight-only | broken>
- Recognize: closest prior pattern = ...
- Test: smallest safe test = ... (or "n/a — chaotic")

## System type: <Clear | Complicated | Complex | Chaotic>
<rationale; note any layered sub-systems and their types>

## Traps present
- Incentives / cobra effect: ...
- Delayed feedback (lag): ...
- Wrong-approach risk: ...

## Recommended protocol
<concrete next actions matched to the type(s)>

## Verify direction
- Mentor / Data / Time signal to watch: ...

## Binary check
<is the either/or real, or a design limit?>   (omit if no binary in the prompt)

Notes

• If the prompt is genuinely chaotic, lead with the stabilizing action — do not make the user wait through a full analysis.
• Keep the diagnosis proportional to the stakes. A small decision needs a few lines, not the whole template.
• If essential parts are unknown, say what you'd need to observe rather than guessing the pattern.