Каталог готовых скиллов/агентов для Claude Code — отчёт для Лучиана

0. Коротко: что это и зачем

Ты уже знаешь правило «повторил дважды → оформи скиллом». Оказывается, десятки людей на GitHub уже прошли этот путь до тебя и выложили готовые «рецепты» — субагентов и команды для Claude Code. Это как база готовых протоколов лечения: не изобретать заново, а брать проверенный протокол и адаптировать под пациента. Ниже — перепись того, что реально лежит в открытом доступе, и что из этого стоит взять для твоего завода.

1. Сколько всего найдено и где

Собран единый файл: /home/claude/mas-research/skills-catalog/catalog.jsonl (302 записи), склеенный из трёх частей классификации (classified-1.jsonl, classified-2.jsonl, classified-3.jsonl) плюс исходный индекс index.jsonl.

Итого 302 «единицы» из 6 разных GitHub-репозиториев:

Это только часть общей библиотеки-зеркала — в /home/claude/skills-mirror/ реально лежит 39 репозиториев (включая официальный anthropics/skills, obra/superpowers, wshobson/agents, microsoft/power-platform-skills и др.), но классификация по ценности (cat/value) в данный момент прогнана только по этим шести — это тот срез, что уже размечен по категориям и полезности.

По типу: - Агенты (субагенты, .md-персоны с ролью/экспертизой) — 221 - Команды (/slash-команды, готовые workflow-скрипты для Claude Code) — 81 - (Отдельного типа «skill» — папка с SKILL.md — в этой конкретной классифицированной выборке нет; skills как формат разбираются отдельно в разделе 3 на живых примерах из skills-mirror/.)

По категориям (cat):

По ценности (value, шкала 1–5, выставлена классификатором):

Итого 54 единицы с value≥4 — это и есть практический шортлист «бери не глядя».

Важный перекос: доминирует dev (классический софтверный код-ревью/архитектура), а вот твои реальные болевые точки — research/ресёрч ниш и content/контент-фабрика — представлены слабо и почти без топ-оценок (в этой выборке 0 записей с value≥4 в категориях research и content). Значит, готовых «из коробки» скиллов под YouTube-заводы и разведку рынков в этих шести репо почти нет — там сила в другом (девелопмент и оркестрация), а контент-конвейер тебе придётся собирать самому или искать в других 33 репозиториях зеркала (там есть и медиа-специфичные штуки, например faceless-script-skill, zenn-visual-creator и т.п. — это уже твои собственные, кастомные скиллы, а не из публичных каталогов).

2. Шортлист по категориям (value ≥ 4) — зачем заказчику

2.1 dev — разработка (26 из 54, самая насыщенная категория)

Это прямое попадание в твой приоритет №1 — «строитель приложений». Вот кого стоит взять:

• system-architect, api-architect, microservices-architect, event-driven-architect, graphql-architect — набор архитекторов для разных стилей систем. Зачем: когда ночной строитель решает «как собрать сайт/тулзу», ему нужен не один универсальный совет, а специалист под конкретный паттерн (REST vs GraphQL vs событийная архитектура) — экономит раунды исправлений.
• backend-typescript-architect / python-backend-engineer / backend-developer — конкретные backend-исполнители под разные стеки. Зачем: твой оркестратор сможет выбирать исполнителя по языку проекта вместо одного «серого» кодера.
• frontend-architect, cs-frontend-engineer, Frontend-Developer (Universal UI Builder) — фронтенд-слой строителя сайтов/тулз (React/Next.js, отзывчивый UI). Прямое попадание в «построй сайт по одной команде».
• fullstack-engineer, cs-fullstack-engineer + команды /cs:fullstack-review, /cs:frontend-review — готовые ревью-циклы «сборка → критика». Это ровно твой паттерн план→код→критика→тест из профиля.
• code-reviewer, code-archaeologist — критик кода и «археолог» для разбора legacy/чужого кода (полезно, когда система лезет в твои существующие 26 репо завода).
• ai-engineer, llm-architect, ml-engineer, nlp-engineer, prompt-engineer, etl-specialist, data-engineer — блок для тех случаев, когда строитель делает не сайт, а ИИ-фичу (например, RAG для memory-bank, промпт-инжиниринг для агентов).
• python-expert — универсальный питон-исполнитель с современными паттернами (Python 3.12+).

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

2.2 orchestration — координация агентов (13 из 54)

Это прямое попадание в твой второй по важности запрос — «как оркестрировать субагентов и экономить токены».

• tech-lead-orchestrator, team-configurator (value 5, топ-оценка) — «технический лид», который на старте проекта решает какую команду субагентов собрать и как её настроить. Зачем: это готовый шаблон твоего собственного оркестратора завода — можно скопировать логику распределения задач.
• multi-agent-coordinator, task-coordinator, cs-engineering-lead — координация параллельных агентов и распределение задач. Прямое попадание в паттерн «запусти N = параллельно» из твоих 5 законов.
• context-manager — управление контекстным окном. Зачем: это прямое решение твоей боли №1 (токеномика) — готовый агент, чья единственная задача следить, чтобы контекст не раздувался.
• knowledge-synthesizer — синтез информации из разных источников. Полезно для этапа «память уроков» (что сработало).
• performance-monitor — отслеживание производительности агентов. Заготовка для будущего дашборда $/задача.
• Команда Steps (несколько вариантов: парсинг workflow-спецификаций, сохранение состояния сессии, сворачивание сессии с отчётом, планирование архитектуры) — это готовый механизм чекпойнтов и компакции между этапами, то есть прямое решение твоей проблемы «12+ шагов → 1M токенов».
• project-analyst — анализ незнакомой кодовой базы (полезно, когда ночной агент впервые видит один из твоих 26 git-репо).

Зачем заказчику: это самая стратегически ценная категория для тебя лично — не «что построить», а «как рулить бригадой строителей», что и есть ядро твоей будущей ОС.

2.3 ops — инфраструктура (9 из 54)

• devops-engineer / DevOps Engineer / Python DevOps-CI/CD Expert — автоматизация CI/CD, Docker. Пригодится когда система сама разворачивает новый сервис на твоём VPS/сервере.
• cloud-architect — мультиоблачная инфраструктура и оптимизация расходов. Полезно для решения «где хостить» (VPS vs GPU по требованию vs домашний ПК).
• kubernetes-specialist, platform-engineer — для будущего, если завод перерастёт docker-compose в оркестрацию контейнеров.
• security-engineer — IAM и инфраструктурная безопасность. Важно: единственная красная линия у тебя — деньги, и агент, который следит за секретами/доступами, снижает риск случайной утечки ключей ночью.
• sre-engineer — SLO и реакция на инциденты. Зачем: ночная автономия требует, чтобы кто-то отслеживал «жив ли сервис» без тебя.
• performance-optimizer — оптимизация производительности систем в целом (не только токенов, но и рантайм).

Зачем заказчику: это «иммунная система» твоего завода — агенты, которые следят за инфраструктурой, пока ты спишь, и являются кандидатами на роль «ночного дежурного».

2.4 business — стратегия и финансы (6 из 54)

• product-strategy-advisor, cs-product-strategist — стратегические решения по продукту, OKR, конкурентный анализ. Годится для режима «консультант-фабрика»: когда система анализирует боли бизнеса клиента.
• cs-financial-analyst, Finance Lead (CFO-сервисы) — DCF-валюация, финмоделирование SaaS, финансовое планирование. Прямое попадание в «опасность-разведчик» — агент, который считает экономику MVP-решений для клиентов.
• cs-ceo-advisor, cs-cto-advisor — стратегия уровня CEO/CTO. Полезно как «второе мнение» перед тем, как система утром идёт с демо к клиенту.

Зачем заказчику: это заготовка твоего «опportunity scout» и панели для оценки MVP-вариантов в режиме консультанта — но заметь, готовых узкоспециализированных агентов под «анализ ниши кофейни» или «розничный бизнес» тут нет, это универсальные консультанты, которых придётся дообучать твоими промптами.

2.5 research и content — пусто в топе

В размеченных 302 записях нет ни одного агента/команды с value≥4 в категориях research (ресёрч, данные, вики) и content (контент-стратегия). Значит, самая близкая к твоему бизнесу область (разведка ниш, YouTube-конвейер) не покрыта этими каталогами на уровне «эталон». Есть лишь среднего качества (value=3) кандидаты: search-specialist (поиск информации), business-analyst (требования/процессы), Python Web Scraping Expert (скрейпинг), Content Strategist (построение контент-движка), группа cs-wiki-* (ингест/поиск/линтинг знаний — потенциально полезно для твоего memory-bank как внешней вики).

Вывод: контент-фабрику (ниши, YouTube, соцсети) тебе придётся собирать почти полностью самому — здесь готовые каталоги не заменяют твой уже работающий завод (niche-finder, cracker, thumbnail-studio), а на GitHub эта ниша слабо покрыта именно потому, что это твоё конкурентное преимущество.

3. Как устроен формат SKILL.md — разбор на живых примерах

В /home/claude/skills-mirror/ — 39 репозиториев, часть из них организована именно как «skills» (папка с файлом SKILL.md внутри), а не просто список агентов/команд. Посмотрел три реальных примера:

Пример 1 — anthropics/skills/skills/skill-creator/SKILL.md (официальный, эталонный)

---
name: skill-creator
description: Create new skills, modify and improve existing skills, and measure
  skill performance. Use when users want to create a skill from scratch, edit,
  or optimize an existing skill, run evals to test a skill, benchmark skill
  performance with variance analysis, or optimize a skill's description for
  better triggering accuracy.
---

# Skill Creator
...(дальше обычный markdown: разделы, пошаговый процесс, советы по общению с пользователем)...

Формат простой: YAML-«шапка» (frontmatter) с двумя обязательными полями — name (машинное имя) и description (то самое поле, по которому Claude решает, когда автоматически подключить этот скилл — это как показания к применению в инструкции лекарства, только их читает не пациент, а сам агент-диспетчер). Дальше — обычный markdown-текст: описание, пошаговый процесс, примеры, ссылки на вспомогательные скрипты в той же папке.

Пример 2 — obra/superpowers/skills/subagent-driven-development/SKILL.md

---
name: subagent-driven-development
description: Use when executing implementation plans with independent tasks in the current session
---

# Subagent-Driven Development

Execute plan by dispatching a fresh implementer subagent per task...
**Why subagents:** ...isolated context...
**Core principle:** Fresh subagent per task + task review...

Здесь та же структура (frontmatter + markdown), но внутри — не общий гайд, а очень конкретный workflow-протокол с диаграммами dot (граф решений «когда использовать этот скилл, а когда соседний»), явными правилами непрерывного выполнения без пауз на подтверждение. Это ближе всего к твоему формату «оформи скиллом» — узкий, protokol-подобный, воспроизводимый.

Пример 3 — anthropics/skills/skills/mcp-builder/SKILL.md

---
name: mcp-builder
description: Guide for creating high-quality MCP servers...
license: Complete terms in LICENSE.txt
---

# MCP Server Development Guide
## Overview
...
# Process
## 🚀 High-Level Workflow
### Phase 1: Deep Research and Planning
...

Более объёмный «гайд-скилл»: многофазный процесс (исследование → планирование → реализация → тест), с эмодзи-разметкой разделов и отсылками к внешней документации по URL. Показывает, что скилл может быть не просто короткой инструкцией, а целой методичкой на несколько тысяч слов — Claude читает её только когда description совпал с задачей (экономия контекста: скилл не загружается «просто так»).

Итог по формату: SKILL.md = (1) YAML-шапка с name + обязательно ёмким description (это триггер автозагрузки — именно на нём Claude матчит намерение пользователя, поэтому его пишут как можно конкретнее, с примерами фраз-триггеров), плюс опционально license; (2) markdown-тело любой длины — от короткого протокола до целой методички; (3) папка скилла может содержать вспомогательные файлы (скрипты, шаблоны, референсы), на которые тело ссылается. Это ровно то, что тебе нужно для правила «повторил дважды → оформи скиллом»: не нужен код, просто формализованный markdown-протокол с чётким «когда включаться».

4. Стратегия для заказчика: что брать готовым, что писать своё

Брать готовым (adopt as-is или с лёгкой правкой): 1. Весь блок orchestration (tech-lead-orchestrator, multi-agent-coordinator, context-manager, команды Steps) — это готовые каркасы твоего собственного оркестратора и решение токеномики. Копировать и адаптировать под факторы твоего завода (channel-hq, memory-bank). 2. Блок dev-архитекторов и ревьюеров (system-architect, code-reviewer, fullstack-review) — прямой строительный материал для «строителя приложений» №1. Не изобретать эти роли заново, взять и подключить. 3. Блок ops (devops-engineer, sre-engineer, security-engineer) — как есть, под «ночного дежурного» инфраструктуры. 4. Формат SKILL.md как таковой — использовать 1-в-1 (frontmatter name/description + markdown-тело), не выдумывать свой формат. 5. Скиллы официального anthropics/skills (skill-creator, mcp-builder и др.) — эталонная база знаний «как писать хорошие скиллы», взять как референс-библиотеку.

Писать своё (доработка обязательна): 1. Весь контент/research-слой под YouTube-заводы и разведку ниш — здесь в публичных каталогах пусто (0 value≥4). Твой niche-finder, cracker, thumbnail-studio и client_interviewer — уже более продвинутые инструменты, чем то, что есть в открытом доступе. Не трать время на поиск замены — расширяй своё. 2. Opportunity scout (разведчик денежных возможностей) — business-агенты из каталога дают общую стратегию (product-strategy-advisor, финансист), но никто не заточен под «просканируй рынок и посчитай ROI для этого конкретного клиента» — собирать самому поверх готовых финансовых/стратегических агентов как строительных блоков. 3. MVP-фабрика для консультант-режима (веер 3–10 решений + судейская панель) — паттерн есть в оркестрации (multi-agent-coordinator + team-configurator), но конкретный «конвейер: боль клиента → ночь → 3–10 MVP → ранжирование» нужно собрать самому, комбинируя готовые dev + orchestration + business агентов. 4. Guardrails под твои 5 законов (стоп-кран на траты, скрипт вместо LLM, персистентная FIFO-очередь) — это твои личные правила, в каталогах их нет, писать как отдельные скиллы/хуки.

Практический план сборки библиотеки: - Свести все 54 записи value≥4 в одну папку skills/ (или agents/ для Claude Code), переписать их description по твоему домену (медицинские аналогии не нужны в description — там пишут для агента-диспетчера, а не для тебя). - На каждый повторяющийся ручной шаг в заводе (как ты уже формулируешь правило) — заводить SKILL.md по образцу subagent-driven-development: короткий, протокольный, с явным «когда включаться». - Раз в месяц гонять новый обход тех же 39 репозиториев зеркала (skills-mirror/) — экосистема растёт быстро, а твоя ниша (контент-фабрики) сегодня непокрыта, но может появиться.

Файлы

• Сводный каталог: /home/claude/mas-research/skills-catalog/catalog.jsonl (302 записи)
• Источники по частям: /home/claude/mas-research/skills-catalog/classified-1.jsonl, classified-2.jsonl, classified-3.jsonl
• Общий индекс (302 записи, тот же набор): /home/claude/mas-research/skills-catalog/index.jsonl
• Зеркало всех 39 репозиториев с примерами SKILL.md: /home/claude/skills-mirror/