210 скиллов: как разобраться в зоопарке AI-ассистентов

Когда папка ~/.agents/skills/ разрастается до двухсот с лишним директорий, наступает момент, когда хочется всё «причесать». Но прежде чем объединять — нужно научиться читать эту коллекцию как систему.

Введение

В любом зрелом инструментальном стеке рано или поздно накапливается технический долг. У AI-агентских skills это проявляется особенно остро: каждый навык — это отдельная папка с SKILL.md, плюс набор references/, scripts/, assets/. Когда их становится больше сотни, появляются естественные вопросы: что с чем пересекается? Какие скиллы можно схлопнуть без потерь, а какие трогать категорически нельзя?

Я разобрал коллекцию из 210 скиллов в /home/dev/.agents/skills/ и попробовал выделить кандидатов на безопасное объединение. Результат оказался скромнее, чем интуитивно ожидалось: всего ~16 скиллов действительно пересекаются по функциональности, и ещё ~7 можно условно объединить при готовности к лёгкой потере эргономики. Остальные 187 скиллов — это либо специализированные ниши, либо стадии спроектированных pipeline’ов, которые намеренно разнесены.

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

Метод группировки

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

custom-indicator (singular) — это создание нового индикатора через Numba JIT, шаблон на 148 строк
custom-indicators (plural) — это 9 готовых crypto on-chain метрик (NVT, MVRV, holder momentum), упакованных в один скрипт

Имена почти одинаковые, но первая — про “напиши мне новый индикатор по шаблону”, вторая — про “вот тебе готовые формулы, примени их к Solana-токену”. Слить их — значит получить 500+ строк, в которых не разберёшься.

Поэтому при анализе каждого скилла я задавал семь вопросов:

Какую задачу решает? Не «что написано в description», а какая реальная боль.
Что подаёт на вход? (файл, JSON, рыночные данные, OHLCV, GitHub issue)
Что выдаёт на выход? (скрипт, отчёт, YAML-тикет, модифицированные файлы)
Какая библиотека / стек? (vectorbt vs backtrader vs ziplime — это разные миры)
Какой артефакт — файл, инлайн, PR? (одна команда в чат или полноценный pipeline)
Где он в lifecycle? (настройка → создание → запуск → валидация? или независимо?)
С какими скиллами имеет handoff? (явная передача данных и ответственности)

Только ответы на все семь дают реальную картину. Когда ответы сходятся по 2-3 скиллам — это кандидат на merge. Когда расходятся принципиально (другая библиотека, другой артефакт, другая стадия) — нужно держать раздельно, даже если имена похожи.

Общая философия: pipeline vs категория

Два скилла, делающие «одно и то же» на поверхности, могут радикально отличаться по архитектурному замыслу:

Категорийная группировка — это когда у вас есть много разных задач одного домена. Например, Mantine: combobox, form, custom-components — это разные подсистемы одной UI-библиотеки. Они пересекаются по домену, но их нельзя слить без разрушения фокуса: @mantine/form — это вообще отдельный npm-пакет.

Pipeline-группировка — это когда у вас одна большая задача разбита на последовательные стадии с явными контрактами. Лучший пример в моей выборке — Edge Pipeline:

hint-extractor → concept-synthesizer → strategy-designer → strategy-reviewer → candidate-agent
                ↑ (orchestrator оборачивает все 5)
                ↑ (signal-aggregator — POST-pipeline cross-skill)

У каждой стадии строгий data contract на входе и выходе: hints.yaml → edge_concepts.yaml → strategy_drafts/*.yaml → review.yaml → strategy.yaml. Orchestrator умеет --resume-from drafts и --review-only — это работает только потому, что стадии разделены. Слить их в один монолит = потерять resumability, тестируемость, single-responsibility.

Поэтому в моём анализе «можно объединить» — это редкий случай, а не норма. Норма — это либо специализированные ниши (TA-Lib vs pandas-ta, где пользователь осознанно выбирает), либо спроектированные handoff’ы (Mantine подсистемы, Kanchi 3-стадии).

Карта результатов

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

Группа	Что внутри	Реальное пересечение	Действие
VectorBT-стек	`backtest` + `optimize` + `quick-stats`	Идентичный OpenAlgo+TA-Lib+vbt pipeline	MERGE в один с `--mode`
OpenAlgo Indicators	5 тонких обёрток	Все делегируют к `indicator-expert`	MERGE в invocable-хаб
TDD + Refactoring	`refactoring` + `clean-code-refactoring`	Первый = Step 4 TDD в standalone	MERGE в `tdd`
Tax Layers	7 скиллов учёта/налогов	`regulatory-reporting` дубль `crypto-tax-export`; `wash-sale` дубль TLH	MERGE 2 пары
HTML Artifacts	40+ шаблонов	6 business-doc делят 90% workflow	CONDITIONAL MERGE
Edge Pipeline	7 стадий	Single-responsibility, handoff-контракты	KEEP ALL
Что НЕЛЬЗЯ (Mantine, Microstructure, Kanchi)	Разные ниши под похожими именами	Ловушка нейминга	KEEP + перелинковать

Каждая строка — это отдельная статья с детальным разбором, что внутри каждого скилла, какие методы он использует, какие уникальные знания содержит.

Чего я НЕ делал

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

Я не запускал скиллы — анализ по содержимому файлов, не по runtime-поведению
Я не оценивал качество отдельных скиллов (для этого есть dual-axis-skill-reviewer — отдельная дисциплина)
Я не предлагал готовый PR на слияние — только карту кандидатов с обоснованием
Я не касался маленьких stub-ов вроде pinescript-to-python-translator (39 строк, 0 кода) подробно — это очевидные кандидаты на удаление

Если вам нужен scoring качества конкретного скилла — dual-axis-skill-reviewer выдаст 0-100 балл с разбивкой по осям и списком улучшений. Эта серия — про архитектурную рациональность коллекции, не про quality gates.

Итоги

Когда коллекция скиллов переваливает за сотню, самое важное — не начать объединять всё подряд, а научиться различать:

Похожие имена ≠ пересечение функций (custom-indicator vs custom-indicators)
Pipeline-стадии ≠ дубликаты (Edge 7-стадий)
Похожий workflow ≠ одинаковый артефакт (business-docs vs dashboards)
Противоречащие правила = разные продукты (vectorbt vs vectorbt-expert)

Семь вопросов на каждый скилл — это медленно, но это единственный способ не наделать ошибок при попытке всё «упростить».

Дальше — детальные разборы по каждой группе.