К основному содержанию
скилл CX Codex

thinking-systems — скилл для Claude Code: системная карта и точки

Скилл для разбора проблем, которые не чинятся локально: строит карту системы, находит петли обратной связи и ранжирует вмешательства по рычагу.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add tjboudreaux/cc-thinking-skills --skill thinking-systems -a claude-code
Открыть на GitHub

Что делает thinking-systems

Скилл включается, когда симптом расползается по нескольким сервисам или компонентам, а точечные правки не держатся: починил в одном месте — сломалось в другом. Вместо поиска виноватой строки он разбирает задачу как структуру и взаимодействие.

Работа идёт по шагам. Сначала очерчивается граница системы: цель, участники, входящие и исходящие потоки. Потом перечисляются накопители (глубина очереди, техдолг, размер кэша, WIP) и скорости, которые их наполняют и опустошают. Дальше находятся петли обратной связи: усиливающие против балансирующих, со знаками связей и задержками вроде TTL, отставания деплоя или метрики. Если проблема возвращается, скилл сверяет структуру с типовыми архетипами — «Fixes That Fail», «Shifting the Burden», «Limits to Growth» и другими. Архетип подставляется только при признаках повторяемости.

На выходе — блок с границей, накопителями, петлями, структурным драйвером и ранжированными вмешательствами: от целей и правил до параметров, с оценкой побочных эффектов и сигналов для наблюдения. Есть и защита от переусердствования: если удаление одного компонента полностью объясняет и чинит проблему, скилл велит бросить карту и вернуться к обычной отладке. Ставить его стоит, когда локальные фиксы уже пробовали и они не прижились.

Какие задачи решает

  • разобрать баг, который проявляется только на стыке нескольких сервисов
  • понять, почему правка в одном модуле ломает поведение в другом
  • найти усиливающую петлю, из-за которой инцидент повторяется после каждого фикса
  • отличить структурную причину от ближайшего симптома
  • выбрать вмешательство с наибольшим рычагом и оценить его побочные эффекты

Примеры запросов агенту

  • симптом тянется через три сервиса, локальные фиксы не держатся — построй карту системы и ранжируй вмешательства
  • почему после каждого исправления очередь снова растёт? найди петли и задержки
  • проблема возвращается третий раз, проверь структуру на архетипы и предложи точку воздействия

Как установить thinking-systems

1Через Skills CLI (Vercel)

npx skills add tjboudreaux/cc-thinking-skills --skill thinking-systems -a claude-code

2Вручную: положить файлы

~/.claude/skills/thinking-systems/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/thinking-systems/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о thinking-systems

Как установить thinking-systems в Claude?

Одной командой: npx skills add tjboudreaux/cc-thinking-skills --skill thinking-systems -a claude-code. После этого файл скилла лежит в ~/.claude/skills/thinking-systems/SKILL.md.

Что делает thinking-systems?

Строит карту системы: границу, накопители и потоки, петли обратной связи с задержками. Затем сверяет структуру с типовыми архетипами и ранжирует вмешательства по рычагу с проверкой побочных эффектов.

Когда этот скилл не нужен?

Если баг линеен и живёт в одном компоненте с понятным стеком — его быстрее проследить и починить. При ограничении пропускной способности одной очевидной стадии скилл сам отсылает к теории ограничений.

Исходный текст

SKILL.md · MIT
---
name: thinking-systems
description: When behavior is emergent across components—fixes elsewhere break, loops/delays dominate—map boundary, stocks/flows, feedback, archetypes, then rank leverage.
disable-model-invocation: true
---

# Systems Mapping and Leverage

Treat the problem as structure and interaction, not isolated parts. Map boundary, stocks/flows, loops/delays, and recurring patterns; intervene at the highest feasible leverage after a side-effect check.

## When to Use

- Symptom spans services/components; single-stack fixes fail or bounce.
- A change in one place breaks another; behavior is emergent.
- Problem recurs despite local fixes (structure, not only symptom).
- Need to rank interventions when parameter/buffer tweaks do not stick.

## When NOT to Use

- Single-component linear bug with clear stack/diff—trace and fix.
- Throughput limited by one obvious stage—use theory-of-constraints.
- Decision is a consequence chain of one proposed action—use second-order.
- Approach selection (plan vs probe vs stabilize)—use cynefin first.

## Procedure

1. **Bound the system.** Name purpose, actors, boundary, and in/out flows. Exclude noise outside the decision horizon; include any path that can feed the symptom.
2. **Map stocks and flows.** List accumulating stocks (queue depth, debt, cache size, WIP) and the rates that fill/drain them. Note what changes slowly even when flows jump.
3. **Find feedback and delays.** For each candidate loop: classify reinforcing (amplifies) vs balancing (resists); mark same-direction (+) vs opposite (-) links; name delays (TTL, deploy lag, metric lag, ramp-up). Even count of opposite links → reinforcing; odd → balancing. Long delay + strong correction → overshoot risk.
4. **Match recurring structure when problems return.** Check only if recurrence or policy resistance is present; do not force a pattern:
   - Fixes That Fail — quick fix, delayed worse side effect
   - Shifting the Burden — workaround starves fundamental fix
   - Limits to Growth — growth hits a balancing constraint
   - Tragedy of the Commons — local optima deplete a shared stock
   - Escalation — mutual reaction spiral
   - Success to the Successful — advantage compounds via allocation
   - Growth and Underinvestment — capacity lags demand until crisis
   If none fits after a genuine pass, keep the from-scratch map.
5. **Trace symptom to structure.** Walk upstream along flows and loops; separate proximate symptom from structural driver (interaction, delay, wrong goal, missing info).
6. **Rank interventions by leverage, then side effects.** Prefer higher feasible class: goals/paradigm → rules/information → loop structure (gain, balancing add, delay shorten) → stock/flow topology → buffers/parameters. For each candidate: feasibility, blast radius, delayed reversal risk. Prefer moves that cut harmful reinforcing gain or strengthen needed balancing loops without creating a new commons/escalation.
7. **Stop.** Commit highest feasible intervention plus watch signals for loop/delay response. Re-map only if the structure changes or the intervention fails its watch.

**Stop when** boundary, key stocks/flows, dominant loop(s)+delay(s), optional archetype, and a ranked intervention with side-effect check are stated—or when the problem collapses to a single linear cause.

## Output

```text
boundary: <system purpose and edges>
stocks_flows: <stock → inflow/outflow list>
loops:
  - name: <loop>
    type: reinforcing | balancing
    delay: <where cause lags effect>
    links: <brief +/->
archetype: <name or none>
structural_driver: <one sentence>
interventions_ranked:
  - level: <goals|rules|loops|structure|params>
    action: <what>
    side_effects: <feedback/elsewhere/delay risk>
chosen: <highest feasible>
watch: <signals that confirm or falsify>
```

## Verification

- **Falsify:** If removing one component fully explains and fixes the issue with no cross-effects, systems mapping is wrong—drop to local debug. If utilization shows one fixed stage as the sole cap, switch to theory-of-constraints.
- **Stop:** Do not keep adding loops after the chosen intervention and watch are set.
- **Over-application guard:** No archetype without recurrence evidence. No low-leverage param tweak listed as primary when a feasible higher class exists. Do not recreate standalone archetype/feedback/leverage procedures—those checks live only inside this map.

© tjboudreaux · MIT · tjboudreaux/cc-thinking-skills

Похожие скиллы

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →
sequential-thinking mrgoonie Скилл разбивает сложный анализ на цепочку шагов, пересматривает выводы и строит ветки решений. Пригодится при проектировании систем и поиске скрытых багов. CX Codex +1 1 800установок thinking-partner mattnowdev Скилл, который спорит с вашими допущениями и подбирает ментальные модели под конкретную задачу. Пригодится, когда застряли на выборе или хотите проверить план на прочность. CX Codex +1 536установок good-thinking jwynia Скилл для аудита того, как агент рассуждает: где операции работают впустую и какая ориентация ими управляет. CX Codex +1 513установок thinking-out-loud Shubham Saboo Скилл превращает длинный поток мыслей в проверяемый бриф до начала работы. Пригодится, когда идея приходит голосом, с повторами и сменой решений. CX Codex +1 436установок save-systems gamedev-skills Скилл проектирует сохранение и загрузку состояния игры: что писать в файл, как не потерять его при краше и как читать старые сейвы после патча. CX Codex +1 7 300установок design-systems-slds-apply forcedotcom Скилл учит агента собирать интерфейсы на Salesforce Lightning Design System: подбирать блюпринты, хуки стилей, утилитарные классы и иконки. CX Codex +1 6 000установок

Из того же набора27

thinking-red-team Скилл для авторизованного разбора безопасности: моделирует атакующего, ищет пути эксплуатации и проверяет, что предложенное исправление закрывает дыру. CX Codex +1 669установок thinking-pre-mortem Разбирает план релиза или задачи от обратного: объявляет провал свершившимся фактом, ищет реальные причины и превращает их в проверки до старта. CX Codex +1 660установок thinking-theory-of-constraints Скилл для ИИ-агента, который помогает найти единственное ограничение в потоке задач и улучшать только его. Пригодится, когда добавление мощностей не поднимает общую скорость. CX Codex +1 643установок thinking-socratic Скилл выявляет скрытые допущения и неточные формулировки до написания кода. Помогает агенту задать ключевой вопрос вместо слепого угадывания требований. CX Codex +1 626установок thinking-opportunity-cost Скилл заставляет агента считать упущенную выгоду перед запуском фич или рефакторинга. Он оценивает дельту ценности между выбранным решением и лучшей альтернативой. CX Codex +1 610установок thinking-model-router Скилл-маршрутизатор: по домену и типу задачи выбирает один подходящий thinking-скилл или честно отвечает NONE. Нужен, когда непонятно, какой подход применить. CX Codex +1 605установок thinking-steel-manning Скилл заставляет агента собрать сильнейшие аргументы оппонента перед отклонением или одобрением архитектурного плана. Это спасает от поспешных решений и поддакивания пользователю. CX Codex +1 600установок thinking-second-order Разбирает последствия решения после первого эффекта: реакцию участников, сроки, вероятность и обратную связь. Нужен для архитектурных и стратегических изменений. CX Codex +1 601установок

Спонсоры проекта

Компании, которые помогают держать аналитику открытой