Жемчужины каталога: orchestration (оркестрация, субагенты, память, токеномика)

Категория «organism-level» для будущей ОС Лучиана: как связать десятки субагентов в единый организм, не сжечь бюджет на перечитывании контекста, и наладить конвейер план → критика → тест. Отобрано ~30 самых применимых скиллов/агентов из 1321 записей категории orchestration.

1. Контекст и токеномика (главная боль Лучиана — «монстр, кушающий $1000/мин»)

context-manager

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/agents/orchestration/context-manager.md
• Что делает: субагент, специализирующийся на оптимизации контекстного окна — прогрессивная подгрузка данных (progressive loading) и стратегическая компакция (сжатие истории вместо перечитывания сырья).
• Зачем Лучиану: это буквально решение его проблемы «контекст раздувался до ~1M токенов» — готовый паттерн, как оркестратор должен передавать субагентам выжимки, а не всю историю.

performance-monitor

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/agents/orchestration/performance-monitor.md
• Что делает: мониторит выполнение агентов, считает расход токенов, измеряет качество ответов, ищет узкие места workflow.
• Зачем: основа для его требования «мониторинг расходов в веб-панели: $/задача, $/день, алерты».

agent-orchestration-context-manager / context-management-context-manager

• repo: wshobson_agents
• path: wshobson_agents/plugins/agent-orchestration/agents/context-manager.md (и дубль в plugins/context-management/agents/context-manager.md)
• Что делает: «элитный» специалист по контекст-инжинирингу — динамическое управление контекстом, векторные БД, графы знаний, интеллектуальные системы памяти поверх мультиагентных workflow.
• Зачем: более развёрнутая версия context-manager с акцентом на то, как масштабировать это на уровень предприятия — пригодится, когда у Лучиана будет не 3, а 20+ каналов.

Context Restoration / Context Save (context-management-context-restore, context-management-context-save)

• repo: wshobson_agents
• path: wshobson_agents/plugins/context-management/commands/context-restore.md и соответствующий context-save
• Что делает: пара команд — семантическое сохранение состояния проекта («институциональные знания») и его точное восстановление в новой сессии с минимальной потерей информации.
• Зачем: прямая реализация его правила «свежая сессия на новый этап вместо продолжения раздутой» — save перед закрытием, restore при следующем шаге.

filesystem-context

• repo: sickn33_agentic-awesome-skills
• path: sickn33_agentic-awesome-skills/skills/filesystem-context/SKILL.md
• Что делает: файл-ориентированное управление контекстом — выгружает данные в файлы и подгружает just-in-time вместо хранения всего в окне модели.
• Зачем: техническая реализация принципа «внешняя память вместо контекста» — ровно то, что уже частично делает memory-bank на его заводе, но здесь — как общий паттерн.

cursor-context-management

• repo: jeremylongshore_claude-code-plugins-plus-skills
• path: jeremylongshore_claude-code-plugins-plus-skills/plugins/saas-packs/cursor-pack/skills/cursor-context-management/SKILL.md
• Что делает: оптимизация контекстного окна через @-упоминания, «context pills» и точечное подключение файлов вместо огромных вставок.
• Зачем: даже если Лучиан не на Cursor, паттерн «явно указывай, что читать» переносится на любые субагенты Claude Code.

lambda-lang

• repo: sickn33_agentic-awesome-skills
• path: sickn33_agentic-awesome-skills/skills/lambda-lang/SKILL.md
• Что делает: компактный «родной язык» для общения агентов друг с другом — 340+ атомов-команд в 7 доменах, сообщения в ~3 раза короче обычного естественного языка.
• Зачем: прямой рычаг экономии токенов на handoff между агентами (оркестратор → воркер → критик) — стоит протестировать на самых частых внутренних сообщениях завода.

senior-prompt-engineer

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/.gemini/skills/senior-prompt-engineer/SKILL.md
• Что делает: оптимизация промптов, eval-driven итерация, метрики RAG (релевантность, точность, покрытие), валидация конфигураций агентов, анализ расхода токенов, дизайн budget-контрактов.
• Зачем: даёт методику измерения «стало ли дешевле/лучше» после изменений в промптах субагентов — важно для его правила «>250k cache-read или >$0.50 — стоп».

agent-harness

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/engineering/agent-harness/skills/agent-harness/SKILL.md
• Что делает: превращает любую папку скиллов домена в ограниченный агентный цикл — компилирует цель в проверяемый план задач, выполняет с машинной верификацией на каждом шаге, ретраи с лимитами, эскалация к человеку при исчерпании бюджета, отказ закрывать задачу без верификации.
• Зачем: готовый каркас именно для «ночной автономии кроме денег» — встроенные стоп-краны и лимиты по бюджету/попыткам.

2. Диспетчеризация субагентов и параллельная работа

dispatching-parallel-agents

• repo: obra_superpowers
• path: obra_superpowers/skills/dispatching-parallel-agents/SKILL.md
• Что делает: правило — если есть 2+ независимые задачи без общего состояния и последовательных зависимостей, запускать их параллельно, а не по очереди.
• Зачем: базовый паттерн под его «запусти N» = параллельно.

subagent-driven-development + Implementer/Task Reviewer Prompt Templates

• repo: obra_superpowers
• path: obra_superpowers/skills/subagent-driven-development/SKILL.md (+ implementer-prompt.md, task-reviewer-prompt.md)
• Что делает: выполнение плана реализации через диспетчеризацию независимых задач субагентам в текущей сессии, с готовыми шаблонами промптов для «исполнителя» и «ревьюера задачи».
• Зачем: прямой шаблон для конвейера «строитель приложений»: план → субагент-кодер → субагент-ревьюер → следующий шаг.

writing-plans (Plan Document Reviewer Prompt Template)

• repo: obra_superpowers
• path: obra_superpowers/skills/writing-plans/plan-document-reviewer-prompt.md
• Что делает: шаблон для диспетчеризации отдельного субагента-рецензента плана перед тем, как план идёт в исполнение.
• Зачем: гейт «критика до и после» — один из его 5 законов, здесь уже готовый темплейт.

requesting-code-review (Code Reviewer Prompt Template)

• repo: obra_superpowers
• path: obra_superpowers/skills/requesting-code-review/code-reviewer.md
• Что делает: шаблон диспетчеризации субагента-код-ревьюера.
• Зачем: блок «критик» в конвейере план→код→критика→тест для builder'а тулз.

hyperflow (весь набор скиллов) — flow-profiles, task-triage, worker-prompt(-lean), review-levels, latency-patterns, project-analysis, dispatch, git-workflow

• repo: jeremylongshore_claude-code-plugins-plus-skills
• path: jeremylongshore_claude-code-plugins-plus-skills/plugins/ai-agency/hyperflow/skills/hyperflow/* (+ skills/dispatch/SKILL.md, skills/trace/*)
• Что делает: почти готовая мини-ОС оркестрации: триаж задачи одной дешёвой моделью → выбор «flow profile» (пресет: число воркеров, число ревьюеров, глубина брейншторма, бюджет контекста, правила параллелизации) → диспетч воркеров по lean-шаблонам → батчевый ревью N сиблингов одним вызовом (а не N вызовов) → авто-git-коммиты по батчам. Отдельно — «Latency patterns P1–P5 + L1–L9» — набор приёмов сокращения числа и стоимости вызовов.
• Зачем: САМАЯ близкая по духу к запросу Лучиана готовая система — конкретно решает «дорого» через архитектуру (batched review вместо последовательных, worker-prompt-lean по умолчанию), а не через обещания. Стоит разобрать эту связку скилл-за-скиллом как референс архитектуры оркестратора.

team-lead / team-implementer + team-composition-patterns / team-communication-protocols / multi-reviewer-patterns / parallel-feature-development / parallel-debugging (пакет agent-teams)

• repo: wshobson_agents
• path: wshobson_agents/plugins/agent-teams/agents/team-lead.md, team-implementer.md, plugins/agent-teams/skills/{team-composition-patterns,team-communication-protocols,multi-reviewer-patterns,parallel-feature-development,parallel-debugging}/SKILL.md
• Что делает: полноценный фреймворк «команды агентов» — лид декомпозирует работу на параллельные задачи с границами владения файлами, ведёт жизненный цикл команды, синтезирует результаты; есть матрица выбора типа субагента по размеру задачи, протоколы сообщений (direct/broadcast, approval, shutdown), консолидация нескольких ревью с дедупликацией находок, параллельное расследование багов через конкурирующие гипотезы.
• Зачем: готовый устав «многоагентной команды» — прямой ответ на вопрос «как раздать роли и не перессорить агентов между собой» для любого из 3 направлений Лучиана.

hub-coordinator / spawn / coordination-strategies / dag-patterns / agent-templates (пакет AgentHub)

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/engineering/agenthub/agents/hub-coordinator.md, engineering/agenthub/skills/agenthub/references/{coordination-strategies,dag-patterns,agent-templates}.md, .gemini/skills/spawn/SKILL.md
• Что делает: запускает N параллельных субагентов в изолированных git worktree, соревнующихся над одной задачей; координатор следит за прогрессом через «доску сообщений», оценивает результаты метрикой или LLM-судьёй и мержит победившую ветку.
• Зачем: прямая реализация ЕГО ключевого паттерна «веер из 3–10 MVP параллельно, сама сравнивает/ранжирует» — это готовый механизм тендера решений, применимый и к MVP для клиентов, и к вариантам обложек/скриптов на заводе.

git-worktree-manager

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/engineering/skills/git-worktree-manager/README.md
• Что делает: безопасный параллелизм через git worktree — изоляция веток, распределение портов, синхронизация окружения, очистка.
• Зачем: техническая «сантехника» под веер параллельных агентов-строителей, чтобы они не топтали друг друга на одном диске.

3. Судьи, критики, консилиумы (прямое попадание в «MVP-фабрику»)

cs-roast-judge

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/productivity/roast/agents/cs-roast-judge.md
• Что делает: собирает состязательную панель из 5 ролей (Критик, Чемпион, Аналитик, Следователь, Клиент) для оценки бизнес-идеи, затем выступает Судьёй и выдаёт один вердикт GO / RESHAPE / KILL плюс самый дешёвый 48-часовой тест для снятия риска. Пять ревьюеров запускаются параллельно как обычные субагенты с одним и тем же брифом; средние оценки запрещены — судья обязан назвать реальное противоречие и разрешить его.
• Зачем: почти готовый «консультант-фабрика MVP» шаблон — панель ролей + судья без усреднения оценок прямо ложится на его сценарий «боли клиента → веер решений → вердикт».

board-meeting

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/.gemini/skills/board-meeting/SKILL.md
• Что делает: протокол «совета директоров» — структурированное 6-фазное обсуждение: загрузка контекста → независимые вклады C-suite-ролей (изолированно, без взаимного влияния) → анализ критика → синтез → ревью основателя → извлечение решения.
• Зачем: альтернативная/дополняющая cs-roast-judge форма консилиума — для более «стратегических», а не только продуктовых решений (например, куда расширять контент-фабрику).

eval-judge

• repo: wshobson_agents
• path: wshobson_agents/plugins/plugin-eval/agents/eval-judge.md
• Что делает: LLM-судья для оценки качества плагинов/скиллов — баллы по точности триггеринга, пригодности к оркестрации, качеству вывода, калибровке охвата, по «заякоренным» рубрикам.
• Зачем: пригодится для его правила «повторил дважды → оформи скиллом» — этим агентом можно автоматически оценивать качество новых самодельных скиллов, прежде чем внести их в библиотеку.

4. Оркестраторы верхнего уровня и мультиагентная координация

workflow-director

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/agents/orchestration/workflow-director.md
• Что делает: end-to-end оркестрация workflow, управление контрольными точками (checkpoints) и восстановление после ошибок.
• Зачем: шаблон верхнего слоя «нервной системы» — как вести многошаговый процесс с точками сохранения, чтобы сбой на шаге 7 не убивал весь ночной прогон.

multi-agent-coordinator

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/agents/orchestration/multi-agent-coordinator.md
• Что делает: координирует параллельное выполнение агентов, управляет зависимостями между ними, сливает результаты нескольких агентов в один.
• Зачем: базовый «диспетчер» для параллельных веток (веер MVP, параллельные каналы).

task-coordinator

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/agents/orchestration/task-coordinator.md
• Что делает: распределение задач между многими агентами, управление зависимостями, параллельное исполнение.
• Зачем: реализация его «персистентной очереди FIFO» (закон №5 — не терять задачи) на уровне мультиагентной системы.

error-coordinator

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/agents/orchestration/error-coordinator.md
• Что делает: обрабатывает ошибки в мультиагентных workflow, реализует стратегии восстановления, предотвращает каскадные сбои.
• Зачем: критично для ночной автономии без присмотра — один упавший субагент не должен ронять весь конвейер.

tech-lead-orchestrator / team-configurator

• repo: vijaythecoder_awesome-claude-agents
• path: vijaythecoder_awesome-claude-agents/agents/orchestrators/tech-lead-orchestrator.md, .../team-configurator.md
• Что делает: tech-lead анализирует сложные задачи разработки и выдаёт структурированную разбивку задач для оптимальной раздачи субагентам; team-configurator сканирует стек проекта и сам подбирает/прописывает нужных специалист-субагентов в CLAUDE.md.
• Зачем: полезно для «строителя приложений» — автоматический подбор нужной команды субагентов под конкретный проект, а не одна команда на все случаи.

ship-mate (orchestrate → architect → implement → review → qa → playwright)

• repo: wshobson_agents
• path: wshobson_agents/plugins/ship-mate/commands/ship.md (+ agents/orchestrate.md, agents/architect.md, agents/qa.md)
• Что делает: полный конвейер разработки одной командой /ship: продукт-оркестратор уточняет спецификацию → архитектор делает пошаговый план с паузой на подтверждение человеком → реализация → ревью → QA-агент гоняет все acceptance-критерии с авто-циклом «нашёл баг → откат на implement» (макс 2 итерации) → визуальная проверка (playwright). Поддерживает /ship status и /ship resume.
• Зачем: это почти буквально пункт 1 его большой цели — «план → код → критика → тест → визуальная проверка → доработка» — уже собранный референс-конвейер, можно разобрать по кускам.

sugar-orchestrator

• repo: jeremylongshore_claude-code-plugins-plus-skills
• path: jeremylongshore_claude-code-plugins-plus-skills/plugins/devops/sugar/agents/sugar-orchestrator.md
• Что делает: координирует автономные workflow разработки со стратегическим надзором.
• Зачем: ещё один пример «надзорного» слоя над автономным исполнением — полезно сравнить с ship-mate и hyperflow по выбранной степени контроля.

overnight-dev-coach

• repo: jeremylongshore_claude-code-plugins-plus-skills
• path: jeremylongshore_claude-code-plugins-plus-skills/plugins/productivity/overnight-dev/agents/overnight-dev-coach.md
• Что делает: автономный «ночной коуч разработки» — принудительно держит TDD-дисциплину, сессии на гейтах git-хуков, итеративно чинит падающие тесты, утром выдаёт отчёт о результатах (когда все тесты зелёные).
• Зачем: прямое попадание в «ночью без него» — конкретный образец, как оформить автономный ночной цикл с утренним хендовером, а не просто декларация.

agent-workflow-designer

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/.gemini/skills/agent-workflow-designer/SKILL.md
• Что делает: проектирует мультиагентные workflow «производственного» уровня — явный выбор паттерна (последовательный/параллельный/иерархический), контракты передачи данных между агентами, обработка отказов, контроль стоимости и контекста.
• Зачем: методологический скилл для проектирования архитектуры оркестратора «с нуля» — полезен на этапе roadmap, до того как писать код.

antigravity-skill-orchestrator / agent-orchestrator

• repo: sickn33_agentic-awesome-skills
• path: sickn33_agentic-awesome-skills/skills/antigravity-skill-orchestrator/SKILL.md, skills/agent-orchestrator/SKILL.md
• Что делает: мета-скилл, который понимает требования задачи, динамически подбирает нужные скиллы, запоминает удачные комбинации скиллов (через agent-memory-mcp) и не даёт применять тяжёлые скиллы к простым задачам (anti-overkill). Второй — сканирует всю экосистему скиллов, матчит по возможностям, ведёт реестр.
• Зачем: это как раз механизм «библиотеки скиллов» — прямой ответ на его пункт «как Лучиану собирать СВОЮ библиотеку скиллов» — автоматический роутинг + защита от расточительного применения тяжёлого скилла к мелкой задаче (тоже экономия токенов).

claude-automation-recommender (+ Subagent Recommendations reference)

• repo: anthropics_claude-plugins-official
• path: anthropics_claude-plugins-official/plugins/claude-code-setup/skills/claude-automation-recommender/SKILL.md
• Что делает: официальный (от Anthropic) скилл — анализирует кодовую базу/проект и рекомендует набор автоматизаций Claude Code: хуки, субагенты, скиллы, плагины, MCP-серверы.
• Зачем: хороший стартовый инструмент буквально для первого этапа стройки системы Лучиана — «что из экосистемы взять готовым» (его же формулировка задачи).

hook-development

• repo: anthropics_claude-plugins-official
• path: anthropics_claude-plugins-official/plugins/plugin-dev/skills/hook-development/SKILL.md
• Что делает: официальный гайд по built-in хукам Claude Code (PreToolUse/PostToolUse/Stop/SubagentStop/SessionStart/PreCompact и др.) — event-driven автоматизация, включая блокировку опасных команд.
• Зачем: механизм для его красной линии «не тратить деньги без подтверждения» — хук на PreToolUse может технически перехватывать любые платные/денежные операции и требовать подтверждения человека, не полагаясь только на промпт-инструкцию.

5. Память и самообучение

memory-kit

• repo: jeremylongshore_claude-code-plugins-plus-skills
• path: jeremylongshore_claude-code-plugins-plus-skills/plugins/productivity/claude-memory-kit/skills/memory-kit/SKILL.md
• Что делает: персистентное управление контекстом между сессиями Claude Code — сохранение/загрузка состояния.
• Зачем: лёгкий стартовый аналог его memory-bank для новых проектов/сайд-проектов, где ещё нет полноценного банка памяти.

Memory Analyst Agent

• repo: alirezarezvani_claude-skills
• path: alirezarezvani_claude-skills/docs/agents/memory-analyst.md
• Что делает: read-only аналитик по ~/.claude/projects/<project>/memory/ — находит «кандидатов на повышение» (записи, доказавшие ценность настолько, чтобы попасть в CLAUDE.md как постоянное правило) и устаревшие записи на удаление.
• Зачем: это прямой механизм «этап 1 самообучения → память уроков» из его плана — автоматический отбор, какие уроки достойны стать постоянным правилом системы, а какие пора забыть.

6. Исследование и веерный ресёрч

deep-dive

• repo: rohitg00_awesome-claude-code-toolkit
• path: rohitg00_awesome-claude-code-toolkit/skills/deep-dive/SKILL.md
• Что делает: «нативный» глубокий ресёрч на базе Claude — DAG-планирование запросов, параллельное исполнение субагентов-исследователей, итерация по обнаруженным пробелам в знаниях. Без внешних API.
• Зачем: годится как основа для агента-«разведчика возможностей» (opportunity scout) — сканирование рынков/трендов параллельными исследовательскими субагентами без необходимости платных API поиска.

bug-hunt-swarm

• repo: sickn33_agentic-awesome-skills
• path: sickn33_agentic-awesome-skills/skills/bug-hunt-swarm/SKILL.md
• Что делает: параллельное read-only мультиагентное расследование первопричины бага/регресса/сбоя, с ранжированным диагнозом на выходе.
• Зачем: паттерн «рой параллельных диагностов» переносится с багов на диагностику причин, почему канал/видео не взлетел (тот же принцип «параллельные гипотезы → ранжирование»).

Выводы

1. Готовая референс-архитектура почти есть — связка hyperflow (триаж → flow-профиль с явным «бюджетом контекста» → lean-промпты воркерам → батчевый ревью одним вызовом вместо N) плюс agent-teams (роли, протоколы сообщений, границы владения файлами) закрывают процентов 70 архитектурных вопросов оркестратора «с нуля» — их стоит разобрать в деталях как основной референс перед проектированием ЕГО системы, а не изобретать заново.

2. Паттерн «веер + судья» для MVP-фабрики уже описан дважды по-разному — cs-roast-judge (5 состязательных ролей + судья без усреднения оценок, вердикт GO/RESHAPE/KILL) и AgentHub hub-coordinator (N параллельных агентов в изолированных worktree, критерий-судья, авто-мерж победителя). Это прямые прототипы его «ночь → 3–10 MVP параллельно → сравнение → утром демо» — можно взять любой как каркас и адаптировать под бизнес-консультации.

3. Токеномика закрывается связкой из 3 слоёв, не одним скиллом: (а) архитектурный — hyperflow/context-manager решают ЧТО не передавать агенту лишнего; (б) операционный — performance-monitor + senior-prompt-engineer считают фактический расход и сигналят о превышении бюджета; (в) механический guardrail — hook-development даёт способ технически заблокировать траты, а не полагаться на послушание модели промпту. Курсу и roadmap стоит явно разделить эти три слоя, иначе «экономия токенов» останется лозунгом.

4. Механизм самообучения (Memory Analyst Agent + antigravity-skill-orchestrator) закрывает оба этапа его плана: сначала — кто решает, какой урок достоин стать постоянным правилом (promotion в CLAUDE.md), затем — кто автоматически подбирает и запоминает удачные комбинации скиллов и блокирует избыточное применение тяжёлых скиллов к мелким задачам. Это готовый ответ на «путь к самоулучшению — система дописывает своих агентов», просто в зачаточной форме — нужно расширять до полноценного «дописывания» новых субагентов, а не только матчинга существующих.

5. Слабое место каталога — устойчивость и денежные гейты: явных примеров «остановись перед тратой денег, спроси подтверждение» в оркестрационной категории немного (кроме hook-development как механизма); паттерны durable workflows/очередей (DBOS, Temporal saga) присутствуют, но заточены под классический бэкенд, а не под мультиагентные LLM-пайплайны — этот кусок (надёжная очередь ночных задач с денежным гейтом) вероятно придётся спроектировать индивидуально, компилируя из нескольких скиллов, а не взять один готовый.