# Systems Thinking

> Use systems thinking to analyze problems driven by dependencies, feedback loops, bottlenecks, local optimizations, and second-order effects. Use when fixing one part changes another, when repeated issues keep resurfacing, or when the real problem is in the surrounding system rather than a single component.

- Skill: `alubiama/systems-thinking` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add alubiama/systems-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alubiama/systems-thinking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: Alubiama (https://skillmd.com/u/alubiama)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/alubiama/systems-thinking

---


# Systems Thinking

## Goal

Reframe a local problem as part of a wider system and identify the highest-leverage intervention point.

The job of this skill is not to make everything abstract. The job is to surface dependencies, loops, bottlenecks, and side effects so action targets the system, not just the symptom.

This skill maps interacting causes. It does not claim the mapped system is complete or validated unless evidence is explicitly provided.

## Default Posture

- system before symptom
- interactions before isolated parts
- second-order effects before quick fixes
- leverage over activity
- bottleneck before optimization

## When To Use

Run this skill when:

- fixing one part causes problems elsewhere
- the same issue keeps recurring
- local optimization does not improve overall outcomes
- there are strong dependencies, queues, loops, or delays
- the problem spans people, process, product, and tooling together

This is a strong next step after:

- `triz` when contradiction interacts with the wider system
- `jtbd` when the job is clear but the delivery system fails
- before prioritization when a local fix may create regressions

## Scope Boundaries

In scope:

- identify system boundaries and actors
- map dependencies, flows, delays, and feedback loops
- detect bottlenecks and local-vs-global mismatches
- surface second-order effects
- recommend the highest-leverage next intervention

Out of scope by default:

- pretending the whole world is in scope
- drawing exhaustive system maps when a focused one is enough
- replacing contradiction solving better handled by `triz`
- replacing problem framing better handled by `jtbd`

## Escalation Conditions

Pause and keep uncertainty explicit when:

- the system boundary cannot be named usefully
- no meaningful dependency or loop can be identified
- the map grows but no leverage point appears
- the problem is actually a local contradiction or weak framing issue

If the model remains too vague after one pass, recommend returning to `jtbd`, `triz`, or narrower validation work.

## Systems Workflow

1. State the focal problem in operational terms.
2. Define the minimum useful system boundary.
3. Identify the main actors, components, queues, or flows.
4. Map key dependencies and delays.
5. Identify reinforcing and balancing loops if they matter.
6. Find the current bottleneck or leverage point.
7. Name likely second-order effects of naive fixes.
8. Recommend the smallest high-leverage intervention and the next validation step.

## Core Questions

Use the minimum set needed:

- What system is this problem part of?
- What are the most important dependencies or flows?
- Where does work, attention, or value accumulate or stall?
- What local fix could worsen the system?
- What loop is reinforcing the current outcome?
- Where is the highest-leverage point for change?

## Output Contract

Always return:

1. `focal_problem`
2. `system_boundary`
3. `key_components`
4. `critical_dependencies`
5. `feedback_loops`
6. `bottleneck_or_leverage_point`
7. `second_order_effects`
8. `evidence_status` (`provided`, `inferred`, `mixed`)
9. `open_unknowns`
10. `recommended_followup` (`systems-thinking`, `jtbd`, `triz`, `selector`, `validation`)
11. `next_intervention`

## Good Systems Signals

Strong signals:

- the same issue repeats despite fixes
- multiple parts interact to produce the outcome
- a queue, delay, or dependency is visible
- local success does not equal system success

Weak signals:

- the issue is contained to one isolated component
- the problem is still undefined
- there is a direct contradiction that should be handled first
- system mapping adds complexity without new insight

## Guardrails

- Do not expand the system boundary without purpose.
- Do not confuse "many factors" with a real system model.
- Do not skip bottleneck identification.
- Distinguish evidence from inference.
- If the problem is really framing or contradiction, recommend `jtbd` or `triz`.
- Prefer one useful leverage point over a giant map with no action.
- If no leverage point emerges, say so instead of inflating the system description.

## Anti-Patterns

Watch for these failure modes:

- system-map theater
- naming many components but no meaningful interactions
- treating every issue as systemic
- optimizing around the bottleneck instead of addressing it
- describing loops without any practical intervention
- expanding scope until action disappears

## Example

User request:

`Support tickets keep rising even though we keep shipping fixes.`

Expected shape of response:

1. `focal_problem`: support volume rises despite ongoing product fixes
2. `system_boundary`: support intake, product defects, release process, docs, onboarding, feedback triage
3. `key_components`: users, support team, product team, release pipeline, help docs, onboarding flows
4. `critical_dependencies`: ticket data to prioritization, release timing to incident load, docs quality to self-service resolution
5. `feedback_loops`: more tickets reduce support bandwidth, weaker triage delays fixes, delayed fixes create more tickets
6. `bottleneck_or_leverage_point`: weak issue categorization and delayed root-cause routing between support and product
7. `second_order_effects`: shipping more low-confidence fixes may increase regressions and documentation drift
8. `evidence_status`: `inferred`
9. `open_unknowns`: which ticket categories dominate, where re-open rates cluster, how release timing correlates with spikes
10. `recommended_followup`: `validation`
11. `next_intervention`: instrument ticket categories and route the highest-volume class through a tighter support-to-product feedback loop