🏠 Главная › user guide › devops kanban orchestrator

{/ This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. /}

Kanban Orchestrator

Decomposition playbook + anti-temptation rules for an orchestrator profile routing work through Kanban. The "don't do the work yourself" rule and the basic lifecycle are auto-injected into every kanban worker's system prompt; this skill is the deeper playbook when you're specifically playing the orchestrator role.

Skill metadata
Source Bundled (installed by default)
Path skills/devops/kanban-orchestrator
Version 3.0.0
Platforms linux, macos, windows
Tags kanban, multi-agent, orchestration, routing
Related skills kanban-worker

Reference: full SKILL.md

ℹ️ Info

The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.

Kanban Orchestrator — Decomposition Playbook

The core worker lifecycle (including the kanban_create fan-out pattern and the "decompose, don't execute" rule) is auto-injected into every kanban process via the KANBAN_GUIDANCE system-prompt block. This skill is the deeper playbook when you're an orchestrator profile whose whole job is routing.

Profiles are user-configured — not a fixed roster

Hermes setups vary widely. Some users run a single profile that does everything; some run a small fleet (docker-worker, cron-worker); some run a curated specialist team they've named themselves. There is no default specialist roster — the orchestrator skill does not know what profiles exist on this machine.

Before fanning out, you must ground the decomposition in the profiles that actually exist. The dispatcher silently fails to spawn unknown assignee names — it doesn't autocorrect, doesn't suggest, doesn't fall back. So a card assigned to researcher on a setup that only has docker-worker just sits in ready forever.

Step 0: discover available profiles before planning.

Use one of these:

Cache the result in your working memory for the rest of the conversation. Re-asking every turn wastes a tool call.

When to use the board (vs. just doing the work)

Create Kanban tasks when any of these are true:

  1. Multiple specialists are needed. Research + analysis + writing is three profiles.
  2. The work should survive a crash or restart. Long-running, recurring, or important.
  3. The user might want to interject. Human-in-the-loop at any step.
  4. Multiple subtasks can run in parallel. Fan-out for speed.
  5. Review / iteration is expected. A reviewer profile loops on drafter output.
  6. The audit trail matters. Board rows persist in SQLite forever.

If none of those apply — it's a small one-shot reasoning task — use delegate_task instead or answer the user directly.

The anti-temptation rules

Your job description says "route, don't execute." The rules that enforce that:

Decomposition playbook

Step 1 — Understand the goal

Ask clarifying questions if the goal is ambiguous. Cheap to ask; expensive to spawn the wrong fleet.

Step 2 — Sketch the task graph

Before creating anything, draft the graph out loud (in your response to the user). Treat every concrete workstream as a candidate card:

  1. Extract the lanes from the request.
  2. Map each lane to one of the profiles you discovered in Step 0. If a lane doesn't fit any existing profile, ask the user which to use or create.
  3. Decide whether each lane is independent or gated by another lane.
  4. Create independent lanes as parallel cards with no parent links.
  5. Create synthesis/review/integration cards with parent links to the lanes they depend on. A child created with unfinished parents starts in todo; the dispatcher promotes it to ready only after every parent is done.

Examples of prompts that should fan out (using placeholder profile names — substitute whatever exists on the user's setup):

Words like "also," "finally," or "and" do not automatically imply a dependency. They often mean "make sure this is covered before reporting back." Only link tasks when one card cannot start until another card's output exists.

Show the graph to the user before creating cards. Let them correct it — including which actual profile name should own each lane.

Use the profile names from Step 0. The example below uses placeholders <profile-A>, <profile-B>, <profile-C> — replace them with what the user actually has.

t1 = kanban_create(
    title="research: Postgres cost vs current",
    assignee="<profile-A>",  # whichever profile handles research on this setup
    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="<profile-A>",  # same profile, run in parallel
    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="<profile-B>",  # whichever profile does synthesis/analysis
    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="<profile-C>",  # whichever profile drafts user-facing prose
    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"]

parents=[...] продвижение по воротам — дети остаются в todo до тех пор, пока каждый родитель не достигнет done, а затем автоматически повышается до ready. Никакой ручной координации не требуется; диспетчер и механизм зависимостей справляются с этим.

Если граф задач имеет зависимости, сначала создайте родительские карты, запишите их возвращаемые идентификаторы и включите эти идентификаторы в список «родителей» дочерней карты во время вызова дочерней карты «kanban_create». Избегайте параллельного создания всех карточек и их последующего связывания; это создает окно, в котором диспетчер может запросить дочерний элемент до того, как появятся его входные данные.

Шаг 4 — Выполните собственное задание

Если вы сами были созданы как задача (например, профилю планировщика было назначено «T0: «исследовать миграцию Postgres»»), отметьте ее как выполненную со сводкой того, что вы создали:

kanban_complete(
    summary="decomposed into T1-T4: 2 research lanes in parallel, 1 synthesis on their outputs, 1 prose draft on the recommendation",
    metadata={
        "task_graph": {
            "T1": {"assignee": "<profile-A>", "parents": []},
            "T2": {"assignee": "<profile-A>", "parents": []},
            "T3": {"assignee": "<profile-B>", "parents": ["T1", "T2"]},
            "T4": {"assignee": "<profile-C>", "parents": ["T3"]},
        },
    },
)

Шаг 5. Отправьте отчет пользователю

Расскажите им, что вы создали, простым языком, назвав фактические профили, которые вы использовали:

Я поставил в очередь 4 задачи: - T1 (<profile-A>): сравнение стоимости - T2 (<profile-A>): сравнение производительности параллельно с T1 - T3 (<profile-B>): синтезирует T1 + T2 в рекомендацию. - T4 (<profile-C>): превращает T3 в памятку CTO.

Диспетчер сейчас заберет Т1 и Т2. Т3 начинается, когда оба заканчивают. Вы получите пинг шлюза после завершения T4. Используйте панель управления или hermes kanban Tail <id>, чтобы следовать дальше.

Общие шаблоны

Разветвление + разветвление (исследование → синтез): N карт исследовательского стиля без родительских элементов, одна карта синтеза, где все они являются родительскими.

Параллельная реализация + проверка: одна карта исполнителя вносит изменения, а другая карта исследователя/исследователя проверяет конфигурацию, документацию или сопоставление источников. Карточка рецензента может зависеть от того и другого. Не делайте разработчику собственную несвязанную проверку только потому, что пользователь упомянул и то, и другое в одном предложении.

Конвейер с воротами: планировщик → исполнитель → рецензент. parents=[previous_task] каждого этапа. Рецензент блокирует или завершает работу; если рецензент блокирует, оператор разблокируется с отзывом и возрождается.

Очередь одного профиля: N задач, назначенных одному и тому же профилю, между ними нет зависимостей. Диспетчер сериализует — этот профиль обрабатывает их в приоритетном порядке, накапливая опыт в собственной памяти.

Человек в цикле: Любая задача может kanban_block() ожидать ввода. Диспетчер возрождается после /unblock. Ветка комментариев содержит полный контекст.

Подводные камни

Придумывание имен профилей, которых не существует. Диспетчер молча не может создать неизвестных исполнителей — карта просто всегда находится в состоянии «готово». Всегда назначайте профиль из вашего открытия на шаге 0; спросите пользователя, если вы не уверены.

Объединение независимых дорожек в одну карточку. Если пользователь запрашивает два независимых результата, создайте две карточки. Пример: «исправить блокировщики и проверить варианты модели» — это не одна задача исправления; создайте карту наладчика/инженера для исправлений и карту исследователя/исследователя для проверки вариантов, а затем, при необходимости, запустите проверку обоих.

Чрезмерное количество ссылок из-за формулировки. «Наконец проверьте X» может все еще быть параллельным реализации, если X — это статическая конфигурация, документация или обнаружение источника. Связывайте его после реализации только тогда, когда проверка зависит от результата реализации.

Забываем ссылки на зависимости. Если в графе задач указано «исследование -> реализация -> проверка», не создавайте все задачи как независимые готовые карточки. Используйте родительские ссылки, чтобы реализация/проверка не могла выполняться до того, как появятся их входные данные.

Переназначение вместо новой задачи. Если рецензент блокирует задачу с надписью «Требуются изменения», создайте НОВУЮ задачу, связанную с задачей рецензента, — не запускайте ту же задачу повторно со строгим взглядом. Новая задача назначается исходному профилю реализатора.

Порядок аргументов для ссылок. kanban_link(parent_id=..., child_id=...) — сначала родительский. Их смешение переводит неправильную задачу в категорию «todo».

Не создавайте заранее весь график, если его форма зависит от промежуточных результатов. Если структура T3 зависит от того, что находят T1 и T2, пусть T3 существует как задача «синтеза результатов», первый шаг которой — считывание родительских передач и планирование всего остального. Оркестраторы могут порождать оркестраторов.

Наследование арендатора. Если в вашей среде установлен HERMES_TENANT, передайте tenant=os.environ.get("HERMES_TENANT") при каждом вызове kanban_create, чтобы дочерние задачи оставались в том же пространстве имен.

Восстановление застрявших рабочих

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

  1. Reclaim (или hermes kanban reclaim <task_id>) — немедленно прервать работающий рабочий процесс и сбросить задачу в состояние «готово». Существующий срок жизни заявки составляет ~15 минут; это быстрый выход.
  2. Переназначить (или hermes kanban reassign <task_id> <new-profile> --reclaim) — переключите задачу на другой профиль (тот, который существует в этой настройке) и позвольте диспетчеру взять ее на себя с помощью нового работника.
  3. Изменить модель профиля — на панели управления печатается подсказка для копирования и вставки для hermes -p <profile> model, поскольку конфигурация профиля находится на диске; отредактируйте его в терминале, затем «Восстановить», чтобы повторить попытку с новой моделью.

Предупреждения о галлюцинациях появляются в задачах, где утверждение kanban_complete(created_cards=[...]) работника включает идентификаторы карт, которые не существуют или не были созданы профилем работника (ворота блокируют завершение), или когда сводка в свободной форме ссылается на идентификаторы t_<hex>, которые не разрешаются (рекомендательное сканирование текста, неблокировка). Оба создают события аудита, которые сохраняются даже после действий по восстановлению — след остается для отладки.