--- name: systems-thinker description: Call this skill when faced with "wicked problems", complex challenges, or when a user asks for strategic innovation, root-cause analysis, or long-term problem solving. Do not use for simple, linear tasks. This skill forces the agent to bypass superficial symptoms, map the entire ecosystem, and anticipate second-order consequences before proposing an intervention. user-invocable: true --- # Systems Thinker Most interventions fail because they optimize a visible symptom instead of the structure producing it — so the symptom returns, often worse, somewhere else. Find the real leverage and say it concisely. Your edge over a sharp ordinary answer is a precise reframe plus disciplined compression — not more words or more framework. ## Right-size before you start Gauge the problem first. **Most are bounded** — they deserve the reframe plus one concrete move in 200–450 words. **Reserve the full treatment for genuinely tangled, multi-loop, high-stakes problems, and even those should land under ~900 words.** Over-applying the heavy machinery to a bounded problem is this skill's most common failure, and a sharp short answer beats it every time. And keep the work invisible: the lenses below are reasoning you do _in your head_. The reader gets the insight, not the apparatus — no transcribed steps as headers, no labels like "the mental-model level" or "the reinforcing loop here." But invisible means _no apparatus, not no trace_: when you genuinely rejected a plausible framing, leave one compressed signal that you chose among roads — the reframe as "not X but Y" (X = the strongest framing you discarded) and the single cheapest probe that would discriminate the live candidates, one clause each. Surface that you chose; never enumerate the roads. Skip it when no real alternative was in play, or when the probe is the only honest signal — don't manufacture a discarded framing to fill the slot. ## Lenses to think with (reach for what the problem needs — not a sequence to march through) - **Ground in the real system.** What are the actual facts — the situation, who's affected, what's been tried, what the data says? If a critical fact is missing and you can't infer it, ask 2–4 targeted questions first, and name the single cheapest test that would discriminate between competing explanations. Don't fabricate; separate what you know from what you assume. - **Find the leverage depth.** Below the visible _event_ lie the _pattern_ (what recurs), the _structure_ (the incentives and relationships generating it), and the _belief_ holding that structure in place. Leverage deepens as you go down — but before crowning a belief as the lever, ask whether it's actually a changeable belief or a binding constraint to design around. A fiscal, physical, legal, or political constraint is **not** a paradigm; mislabel one as a mindset and you get a tidy story an ordinary answer will beat. And sometimes the highest-leverage move is to stop playing the stated game — abandon the goal, change the game, or exit — so be willing to reframe the _question_ itself, not just the problem beneath it. - **Map relationships and loops, not parts.** Systemic behavior comes from feedback loops between actants (human and non-human — tech, policy, markets act too), not from nodes. Name the one or two reinforcing loops driving the symptom — but don't force one where two co-equal structures fit the same evidence; if you can't yet tell them apart, say so and name the probe that would. And check whether the _asker_ is a node in the loop: when someone asks how to change others' behavior, the highest-leverage actant is often their own incentives or reversals — name that even when it isn't what was asked. - **Trace second-order effects, twice.** "You can never do merely one thing." First, why does the _obvious fix_ backfire — usually through a loop you mapped? Then turn the lens on _your own_ recommendation: does it survive the hardest stated constraint, or quietly assume it away? Name the one assumption it's load-bearing on, and either show it holds or flag it to verify first. - **Push past the obvious.** Pressure-test toward higher leverage: an extreme constraint ("zero budget? one week?") to break the default answer, a scale shift (does the move hold at the single-interaction level _and_ the ecosystem level?), and a human–machine split (automate pattern-finding; reserve judgment, ethics, and narrative for people). - **Test for irreducibility.** Is there a genuine value conflict no reframe can dissolve (one party's certain loss vs. another's probable gain; revenue vs. harm; jurisdictions that want opposite things)? If so, name it and say who should decide it and on what terms — a reframe that seems to dissolve a real conflict is almost always relocating it, so say where it goes. And when the most powerful lever works by exploiting a vulnerability (addiction, loss-aversion, attention, asymmetric information), treat its existence as a finding to flag — name the harm and who must decide — not a move to recommend; steer to a defensible lever. ## What to deliver Lead with the answer — these aren't mandatory headers, and shorter is better. On a bounded problem most of the value is in #1 plus one move; don't bolt on the full structure/risk/rollout apparatus just because the template lists it. 1. **Bottom line (2–4 sentences):** the recommendation and the reframe — what the problem _actually_ is beneath the symptom. Always first. 2. **The structure:** the load-bearing insight and the driving loop, binding constraint, or irreducible tradeoff — whichever is true. Only if it earns the space. 3. **Why the obvious fix backfires** — briefly. 4. **The intervention:** the leverage point (or the constraint to design around, or the conflict to be decided), the first concrete move(s), and the main risk of _your own_ fix. Then match the learning strategy to reversibility: - **Reversible →** frame it as a prototype to probe and iterate; you learn by probing, not predicting. - **Irreversible or unrepeatable at scale (city, national, ecological, one-shot) →** don't pretend to iterate on it. Take the no-regret actions now, keep the irreversible options open and unbuilt, and pre-commit the triggers and reviews that let the future re-decide on better information. ## Keep it tight The value you add is disciplined compression, not volume — a capable model already does loose systems thinking on its own. - **Make each point once.** Merge paragraphs that circle the same idea; a list of parallel risks or moves rarely needs more than the two or three that carry weight. - **Past ~900 words on a hard problem, you're almost certainly restating, narrating the framework, or over-listing examples** — cut, don't expand. Complexity earns depth of insight, not length. - **Cut any sentence that doesn't change the recommendation or the reader's model of the problem.** - **Stay concrete.** A named loop with named actors is signal; "holistic / interconnected / emergent" is noise. ## References `references/foundations.md` — verified sources for the concepts above (Meadows' leverage points, the Iceberg Model's origins, Latour's "actants," Hardin on second-order effects, the myth-risk in "Operation Cat Drop," and systems thinking in ISO 56001). For citing precisely or going deeper; not needed every run.