메뉴
Use when debugging across services/an incident where a fix in one place breaks another, or behavior is emergent and no single component explains it. Maps the system and traces causes.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
| name | thinking-systems |
| description | Use when debugging across services/an incident where a fix in one place breaks another, or behavior is emergent and no single component explains it. Maps the system and traces causes. |
Systems thinking views a problem as part of an interconnected whole rather than isolated components. It focuses on relationships, feedback loops, delays, and emergent properties—behaviors that arise from interactions and can't be predicted from parts alone. Its proven payoff is cross-service/incident debugging, where "obvious" single-component fixes fail.
Core Principle: The behavior of a system cannot be understood by analyzing components in isolation. Look at connections, feedback, and emergence.
Problem spans multiple components? → yes → APPLY SYSTEMS THINKING
Fix in one place caused issue in another? → yes → APPLY SYSTEMS THINKING
Behavior seems "emergent" or unexpected? → yes → APPLY SYSTEMS THINKING
This is the core of the skill—apply it first.
Draw components, connections, and data/control flows:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Client │────▶│ API │────▶│ DB │
└─────────┘ └────┬────┘ └─────────┘
│
▼
┌─────────┐
│ Cache │
└─────────┘
For each loop, determine:
Retry Storm Loop (Reinforcing - Dangerous):
Service slow → Clients retry → More load → Service slower → More retries
Follow the symptom backward to find originating cause:
Symptom: High latency in Service C
→ Service C waiting on Service B
→ Service B waiting on Service A
→ Service A doing full table scan (ROOT CAUSE)
What happens when components interact under stress?
One component fails → Dependent components overload → They fail
↓
← More traffic to remaining ←
Mitigation: Circuit breakers, bulkheads, graceful degradation
Cache expires → All requests hit backend simultaneously → Overload
Mitigation: Jittered expiration, cache warming, request coalescing
Processing rate < Arrival rate → Queue grows → Memory pressure → OOM
Mitigation: Backpressure, rate limiting, queue bounds
Multiple processes → Same resource → Lock contention → Serialization
↓
Throughput collapses despite available CPU
Mitigation: Sharding, optimistic locking, resource isolation
Reinforcing (Positive) Loops: Amplify change
Technical Debt Loop:
Deadline pressure → Shortcuts → More bugs → More firefighting
↓
← Less time for quality ←
Balancing (Negative) Loops: Counteract change
Auto-scaling Loop:
Load increases → More instances spawn → Load per instance decreases
↓
← Fewer instances needed ←
Questions to identify loops:
Stocks: Accumulated quantities (users, technical debt, cache size) Flows: Rates of change (registrations/day, bugs fixed/sprint)
┌─────────────────────────────────────┐
│ Inflow → [Stock] → Outflow │
│ │
│ New bugs → [Bug Backlog] → Fixes │
│ Requests → [Queue Depth] → Processed│
│ Hires → [Team Size] → Attrition │
└─────────────────────────────────────┘
Key insight: Stocks change slowly even when flows change quickly. Queue depth doesn't drop instantly when you add capacity.
Time lags between cause and effect obscure relationships:
Code deployed → [Delay: Cache TTL] → Users see change
Feature shipped → [Delay: Adoption curve] → Metrics change
New hire starts → [Delay: Ramp-up] → Productivity impact
Danger: Acting before feedback arrives leads to overcorrection.
Small changes can have large effects (and vice versa):
Linear assumption: 2x traffic = 2x latency
Reality: Traffic crosses threshold → 10x latency (queue buildup)
Linear assumption: Adding engineer adds capacity
Reality: Communication overhead grows O(n²)
Behaviors that arise from interactions, not individual components:
┌──────────────────────────────────────────────────────────────┐
│ System: [Name] │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Factor │──────(+)──────────────▶│ Factor │ │
│ │ A │ │ B │ │
│ └─────────┘ └────┬────┘ │
│ ▲ │ │
│ │ │ │
│ (-) (+) │
│ │ │ │
│ │ ┌─────────┐ │ │
│ └─────────│ Factor │◀─────────────┘ │
│ │ C │ │
│ └─────────┘ │
│ │
│ Legend: (+) = same direction, (-) = opposite direction │
│ Loop type: Reinforcing / Balancing │
└──────────────────────────────────────────────────────────────┘
Once you've located where to intervene, pick the highest-leverage point you can actually move:
| Leverage | Example | Impact |
|---|---|---|
| Parameters | Timeout values | Low |
| Buffer sizes | Queue limits | Low-Medium |
| Feedback loops | Add monitoring | Medium |
| Information flows | Make metrics visible | Medium-High |
| Rules | Change retry policy | High |
| Goals | Redefine SLOs | Very High |
| Paradigm | Rethink architecture | Transformational |
(See thinking-leverage-points for Meadows' full 12-level hierarchy.)
"We can't control systems or figure them out. But we can dance with them."
Systems resist simple fixes. Effective intervention requires understanding the whole, finding leverage points, and accepting that you're influencing, not controlling.