На этой странице Плейбук декомпозиции + соглашения по реестру специалистов + правила защиты от соблазнов для профиля оркестратора, маршрутизирующего работу через Kanban. Правило «не делай работу сам» и базовый жизненный цикл автоматически внедряются в системный промпт каждого kanban-воркера; этот навык — более глубокий плейбук, когда вы конкретно исполняете роль оркестратора.
Метаданные навыка¶
| |
|---|---|
|Источник| Встроенный (устанавливается по умолчанию)
|Путь| skills/devops/kanban-orchestrator
|Версия| 2.0.0
|Теги| kanban, multi-agent, orchestration, routing
|Связанные навыки| kanban-worker
Справочник: полный SKILL.md¶
info Ниже приведено полное определение навыка, которое Hermes загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.
Kanban Оркестратор — Плейбук декомпозиции¶
Основной жизненный цикл воркера (включая паттерн разветвления
kanban_createи правило «декомпозируй, не исполняй») автоматически внедряется в каждый kanban-процесс через блок системного промптаKANBAN_GUIDANCE. Этот навык — более глубокий плейбук, когда вы — оркестратор, чья работа целиком заключается в маршрутизации.
Когда использовать доску (а не просто делать работу)¶
Создавайте Kanban-задачи, когда верно хотя бы одно из следующих утверждений: 1. Нужно несколько специалистов. Исследование + анализ + написание — это три профиля. 2. Работа должна пережить сбой или перезапуск. Долгая, периодическая или важная. 3. Пользователь возможно захочет вмешаться. Человек в цикле на любом этапе. 4. Несколько подзадач можно выполнять параллельно. Разветвление для скорости. 5. Ожидается ревью / итерация. Профиль ревьюера проходит по выводам разработчика. 6. Важен аудиторский след. Строки доски сохраняются в SQLite навсегда.
Если ни одно из них не применимо — это небольшая одноразовая задача на рассуждение — используйте delegate_task или ответьте пользователю напрямую.
Правила защиты от соблазнов¶
В вашей должностной инструкции сказано: «маршрутизируй, не исполняй». Правила, которые это подкрепляют: * Не выполняйте работу сами. Ваш ограниченный набор инструментов обычно даже не включает терминал/файлы/код/веб для реализации. Если вы ловите себя на мысли «да я быстро это поправлю» — остановитесь и создайте задачу для соответствующего специалиста. * Для любой конкретной задачи создавайте Kanban-задачу и назначайте её. Каждый раз. * Если ни один специалист не подходит, спросите пользователя, какой профиль создать. Не делайте работу сами по принципу «ну достаточно близко». * Декомпозируйте, маршрутизируйте и резюмируйте — вот и вся работа.
Стандартный реестр специалистов (соглашение)¶
Если в настройках пользователя нет кастомных профилей, предполагайте, что эти существуют. Подстраивайтесь под то, что есть у пользователя — если не уверены, спросите.
Профиль| Делает| Типичное рабочее пространство
|---|---|---
researcher| Читает источники, собирает факты, пишет выводы| scratch
analyst| Синтезирует, ранжирует, удаляет дубликаты. Потребляет результаты нескольких researcher| scratch
writer| Пишет текст голосом пользователя| scratch или dir: в хранилище Obsidian
reviewer| Читает результат, оставляет замечания, управляет утверждением| scratch
backend-eng| Пишет серверный код| worktree
frontend-eng| Пишет клиентский код| worktree
ops| Запускает скрипты, управляет сервисами, выполняет развёртывание| dir: в репозиторий скриптов ops
pm| Пишет спецификации, критерии приёмки| scratch
Плейбук декомпозиции¶
Шаг 1 — Поймите цель¶
Задавайте уточняющие вопросы, если цель неясна. Дешево спросить; дорого запустить не тот флот.
Шаг 2 — Набросайте граф задач¶
Прежде чем что-либо создавать, набросайте граф вслух (в вашем ответе пользователю). Пример для «Проанализировать, стоит ли мигрировать на Postgres»: [code] T1 researcher исследование: стоимость Postgres vs текущая T2 researcher исследование: производительность Postgres vs текущая T3 analyst синтезировать рекомендацию по миграции родители: T1, T2 T4 writer составить проект решения родители: T3
[/code] Покажите это пользователю. Дайте ему поправить, прежде чем что-то создавать.
Шаг 3 — Создайте задачи и свяжите их¶
[code] t1 = kanban_create( title="research: Postgres cost vs current", assignee="researcher", body="Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS/GCP pricing, team time estimates, current Postgres bills from peers.", tenant=os.environ.get("HERMES_TENANT"), )["task_id"]
t2 = kanban_create(
title="research: Postgres performance vs current",
assignee="researcher",
body="Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.",
)["task_id"]
t3 = kanban_create(
title="synthesize migration recommendation",
assignee="analyst",
body="Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go/no-go call.",
parents=[t1, t2],
)["task_id"]
t4 = kanban_create(
title="draft decision memo",
assignee="writer",
body="Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.",
parents=[t3],
)["task_id"]
[/code]
parents=[...] управляет продвижением — дочерние задачи остаются в todo, пока все родители не перейдут в done, после чего автоматически продвигаются в ready. Ручная координация не требуется; диспетчер и механизм зависимостей всё обрабатывают.
Шаг 4 — Завершите свою собственную задачу¶
Если вы сами были порождены как задача (например, профилю planner была назначена T0: "исследовать миграцию на Postgres"), отметьте её как выполненную с кратким описанием того, что вы создали:
[code]
kanban_complete(
summary="decomposed into T1-T4: 2 researchers parallel, 1 analyst on their outputs, 1 writer on the recommendation",
metadata={
"task_graph": {
"T1": {"assignee": "researcher", "parents": []},
"T2": {"assignee": "researcher", "parents": []},
"T3": {"assignee": "analyst", "parents": ["T1", "T2"]},
"T4": {"assignee": "writer", "parents": ["T3"]},
},
},
)
[/code]
Шаг 5 — Сообщите пользователю¶
Расскажите ему, что вы создали, простым языком:
Я поставил в очередь 4 задачи: * T1 (researcher): сравнение стоимости * T2 (researcher): сравнение производительности, параллельно с T1 * T3 (analyst): синтезирует T1 + T2 в рекомендацию * T4 (writer): превращает T3 в памятку для CTO
Диспетчер сейчас возьмёт T1 и T2. T3 начнётся, когда обе завершатся. Вы получите уведомление на шлюзе, когда T4 будет выполнена. Используйте панель управления или
hermes kanban tail <id>, чтобы следить за процессом.
Типовые паттерны¶
Разветвление + свёртка (исследование → синтез): N задач researcher без родителей, одна задача analyst со всеми ими в качестве родителей.
Конвейер с шлюзами: pm → backend-eng → reviewer. Каждый этап имеет parents=[предыдущая_задача]. Ревьюер блокирует или завершает; если ревьюер блокирует, оператор разблокирует с обратной связью и перезапускает.
Очередь одного профиля: 50 задач, все назначены translator, без зависимостей между ними. Диспетчер сериализует — переводчик обрабатывает их в порядке приоритета, накапливая опыт в собственной памяти.
Человек в цикле: Любая задача может вызвать kanban_block(), чтобы ожидать ввода. Диспетчер перезапускает после /unblock. Ветка комментариев несёт полный контекст.
Ловушки¶
Переназначение против новой задачи. Если ревьюер блокирует с пометкой «требуются изменения», создайте НОВУЮ задачу, связанную с задачей ревьюера — не запускайте ту же задачу заново со строгим взглядом. Новая задача назначается исходному профилю исполнителя.
Порядок аргументов для связей. kanban_link(parent_id=..., child_id=...) — родитель первым. Если их перепутать, неправильная задача понижается до todo.
Не создавайте весь граф заранее, если форма зависит от промежуточных результатов. Если структура T3 зависит от того, что найдут T1 и T2, пусть T3 существует как задача «синтезировать результаты», чей первый шаг — прочитать родительские наработки и спланировать остальное. Оркестраторы могут порождать оркестраторов.
Наследование тенанта. Если HERMES_TENANT установлен в вашем окружении, передавайте tenant=os.environ.get("HERMES_TENANT") при каждом вызове kanban_create, чтобы дочерние задачи оставались в том же пространстве имён.
Восстановление зависших воркеров¶
Когда профиль воркера постоянно падает, галлюцинирует или блокируется собственными ошибками (обычно: не та модель, отсутствующий навык, сломанные учётные данные), панель управления kanban помечает задачу значком ⚠ и открывает раздел Восстановление в панели. Три основных действия:
1. Перезахват (или hermes kanban reclaim <task_id>) — немедленно прервать работающего воркера и сбросить задачу в ready. Существующий TTL захвата ~15 мин; это быстрый путь выхода.
2. Переназначение (или hermes kanban reassign <task_id> <new-profile> --reclaim) — переключить задачу на другой профиль и позволить диспетчеру подхватить её новым воркером.
3. Смена модели профиля — панель управления выводит подсказку для копирования команды hermes -p <profile> model, поскольку конфигурация профиля хранится на диске; отредактируйте её в терминале, затем выполните Reclaim для повторной попытки с новой моделью.
Предупреждения о галлюцинациях появляются на задачах, где утверждение воркера в kanban_complete(created_cards=[...]) включает идентификаторы карточек, которые не существуют или не были созданы профилем этого воркера (шлюз блокирует завершение), или где свободное описание ссылается на идентификаторы t_<hex>, которые не разрешаются (предупредительный анализ текста, не блокирующий). Оба случая создают события аудита, которые сохраняются даже после действий по восстановлению — след остаётся для отладки.
* Метаданные навыка
* Справочник: полный SKILL.md
* Когда использовать доску (а не просто делать работу)
* Правила защиты от соблазнов
* Стандартный реестр специалистов (соглашение)
* Плейбук декомпозиции
* Шаг 1 — Поймите цель
* Шаг 2 — Набросайте граф задач
* Шаг 3 — Создайте задачи и свяжите их
* Шаг 4 — Завершите свою собственную задачу
* Шаг 5 — Сообщите пользователю
* Типовые паттерны
* Ловушки
* Восстановление зависших воркеров