Kanban Orchestrator（看板协调器）

用于协调器角色通过看板路由工作的分解剧本 + 反诱惑规则。“不要亲自执行工作”的规则以及基本生命周期会自动注入到每个看板工作者的系统提示中；当你专门扮演协调器角色时，此技能是更深入的剧本。

技能元数据

来源	捆绑（默认安装）
路径	skills/devops/kanban-orchestrator
版本	3.0.0
平台	linux, macos, windows
标签	kanban, multi-agent, orchestration, routing
相关技能	kanban-worker

参考：完整 SKILL.md

信息

以下是触发此技能时 Hermes 加载的完整技能定义。这是技能激活时代理看到的指令。

Kanban Orchestrator（看板协调器）— 分解剧本

核心工作者生命周期（包括 kanban_create 扇出模式和“分解，不执行”规则）通过 KANBAN_GUIDANCE 系统提示块自动注入到每个看板进程中。当你是一个职责完全是路由的协调器角色时，此技能是更深入的剧本。

配置文件由用户配置 — 并非固定名单

Hermes 的设置差异很大。有些用户运行一个执行所有操作的单一配置文件；有些运行一个小集群（docker-worker、cron-worker）；有些运行他们自己命名的精选专家团队。没有默认的专家名单 — 协调器技能不知道此机器上存在哪些配置文件。

在扇出之前，你必须将分解基于实际存在的配置文件。如果分配给未知的受托人名称，调度程序会静默失败 — 它不会自动纠正、不会建议、也不会回退。因此，在仅拥有 docker-worker 的设置中分配给 researcher 的卡片将永远停留在 ready 状态。

步骤 0：在规划之前发现可用的配置文件。

使用以下方法之一：

• hermes profile list — 打印此机器上配置的配置文件表。如果你有终端工具，请通过它运行；否则询问用户。
• kanban_list(assignee="<some-name>") — 对单个名称进行健全性检查。对于未知的受托人，返回空列表（而不是错误），因此这仅确认你已经在考虑的名称。
• 直接询问用户。 “你设置了哪些配置文件？”当目标需要多个专家时，这是一个很好的首轮问题。

在对话的其余部分将结果缓存到你的工作记忆中。每轮都重新询问会浪费一次工具调用。

何时使用看板（与直接执行工作相比）

当满足以下任何条件时，创建看板任务：

1. 需要多个专家。 研究 + 分析 + 写作涉及三个配置文件。
2. 工作应能在崩溃或重启后幸存。 长期运行、重复性或重要的工作。
3. 用户可能希望介入。 在任何步骤中实现人机协同。
4. 多个子任务可以并行运行。 扇出以提高速度。
5. 预期需要进行审查/迭代。 审查者配置文件对起草者的输出进行循环处理。
6. 审计轨迹很重要。 看板行永久保存在 SQLite 中。

如果都不适用 — 即它是一个小型的一次性推理任务 — 请改用 delegate_task 或直接回答用户。

反诱惑规则

你的职位描述说“路由，不执行”。强制执行此规则的规则如下：

• 不要亲自执行工作。 你的受限工具集通常甚至不包括用于实现的终端/文件/代码/Web 工具。如果你发现自己“只是快速修复这个问题” — 停下来并为合适的专家创建任务。
• 对于任何具体任务，创建看板任务并分配它。 每次都要这样做。
• 在创建卡片之前拆分多车道请求。 用户提示可能包含几个独立的工作流。首先提取这些车道，然后为每个车道创建一个卡片，而不是将不相关的工作捆绑到单个实施者卡片中。
• 并行运行独立的车道。 如果两个卡片不需要彼此的输出，请将它们保持未链接状态，以便调度程序可以将它们扇出。仅链接真正的数据依赖项。
• 切勿将依赖性工作创建为独立的 ready 卡片。 如果卡片必须等待另一个卡片，请在原始的 kanban_create 调用中传递 parents=[...]。不要先创建它然后再链接，也不要依赖正文中的“等待 T1”之类的文字。
• 如果没有专家适合可用的配置文件，请询问用户要创建哪个配置文件或使用哪个现有配置文件。 不要发明配置文件名称；调度程序将静默丢弃未知的受托人。
• 分解、路由和总结 — 这就是全部工作。

分解剧本

步骤 1 — 理解目标

如果目标不明确，请提出澄清问题。询问成本低；启动错误的集群成本高。

步骤 2 — 绘制任务图

在创建任何内容之前，大声草拟出图表（在你的回复中向用户展示）。将每个具体的工作流视为候选卡片：

1. 从请求中提取工作流（lanes）。
2. 将每个工作流映射到你在步骤 0 中发现的某个配置文件（profile）。如果某个工作流不适合任何现有配置文件，请询问用户要使用哪个配置文件或创建一个新的。
3. 确定每个工作流是独立的，还是受另一个工作流的制约（gated）。
4. 创建独立的工作流作为没有父链接的并行卡片。
5. 创建综合/审查/集成卡片，并添加指向其所依赖工作流的父链接。在父任务未完成时创建的子任务初始状态为 todo；只有当所有父任务都完成后，调度器才会将其提升为 ready。

应该进行扇出（fan out）的提示示例（使用占位符配置文件名称——请替换为用户设置中实际存在的名称）：

• “构建一个应用” → 向面向设计的配置文件分配一张卡片以负责产品/UI 方向，向工程配置文件分配一两张卡片以负责实现，如果用户有审查者配置文件，则稍后添加一张集成/审查卡片。
• “修复阻塞问题并检查模型变体” → 为修复阻塞问题分配一张实现卡片，并为配置/源验证分配一张发现/研究卡片。最终的审查者卡片可以依赖于这两者。
• “研究文档并实现” → 文档研究卡片可以与代码库发现卡片并行运行；仅当实现真正需要这些发现时才等待。
• “分析此截图并查找相关代码” → 向具备视觉能力的配置文件分配一张卡片进行视觉分析，同时另一张卡片搜索代码库。

“also”、“finally”或“and”等词语并不自动意味着依赖关系。它们通常表示“在汇报之前确保已涵盖此项”。仅当一个卡片必须等到另一个卡片的输出存在才能开始时，才链接任务。

在创建卡片之前向用户展示图谱。让用户纠正它——包括每个工作流应由哪个实际配置文件名称负责。

步骤 3 — 创建任务并建立链接

使用步骤 0 中的配置文件名称。下面的示例使用占位符 <profile-A>、<profile-B>、<profile-C> — 请将它们替换为用户实际拥有的配置文件。

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=[...] 控制提升（promotion）— 子任务将保持在 todo 状态，直到所有父任务达到 done 状态，然后自动提升为 ready。无需手动协调；调度器和依赖引擎会处理此事。

如果任务图存在依赖关系，请先创建父卡片，捕获其返回的 id，并在子卡片的 kanban_create 调用中将那些 id 包含在子卡片的 parents 列表中。避免并行创建所有卡片然后再链接它们；这会造成一个时间窗口，使得调度器可能在输入存在之前就认领了子任务。

步骤 4 — 完成你自己的任务

如果你自己是作为一个任务被生成的（例如，规划者配置文件被分配了 T0: "investigate Postgres migration"），请通过总结你创建的内容将其标记为完成：

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 的备忘录

调度器现在将接手 T1 和 T2。T3 将在两者完成后开始。当 T4 完成时，你将收到网关通知。使用仪表板或 hermes kanban tail <id> 来跟踪进度。

常见模式

扇出 + 扇入（研究 → 综合）： N 张没有父任务的研究风格卡片，一张以它们全部为父任务的综合卡片。

并行实现 + 验证： 一张实现者卡片进行更改，同时一张探索者/研究者卡片验证配置、文档或源映射。审查者卡片可以依赖于这两者。不要仅仅因为用户在同一个句子中提到了两者，就让实现者负责不相关的验证。

带闸门的流水线： planner → implementer → reviewer。每个阶段的 parents=[previous_task]。审查者阻塞或完成；如果审查者阻塞，操作员通过反馈解除阻塞并重新生成任务。

同配置文件队列： N 个任务，全部分配给同一个配置文件，它们之间没有依赖关系。调度器进行序列化—该配置文件按优先级顺序处理它们，并在其自身记忆中积累经验。

人机协同（Human-in-the-loop）： 任何任务都可以调用 kanban_block() 以等待输入。在执行 /unblock 后，调度器会重新生成任务。评论线程携带完整的上下文。

陷阱

发明不存在的配置文件名称。 调度器会在静默中无法生成未知的指派对象—卡片将永远停留在 ready 状态。始终分配给步骤 0 中发现的配置文件；如果不确定，请询问用户。

将独立的工作流捆绑到一张卡片中。 如果用户要求两个独立的结果，请创建两张卡片。例如：“修复阻塞问题并检查模型变体”不是一个修复者任务；应为修复工作创建一个修复者/工程师卡片，为变体检查创建一个探索者/研究者卡片，然后可选地将审查 gating 在这两者之上。

因措辞而过度链接。 “最后检查 X” 如果 X 是静态配置、文档或源发现，可能仍然与实现并行。仅当检查依赖于实现结果时，才在实现之后链接它。

忘记依赖链接。 如果任务图显示 research -> implement -> review，不要将所有任务创建为独立的就绪卡片。使用父级链接，确保 implement/review 在其输入存在之前无法运行。

重新分配 vs. 新建任务。 如果审查者以“需要修改”为由阻塞任务，请创建一个从审查者任务链接出来的新任务——不要带着严厉的表情重新运行同一个任务。新任务分配给原始实现者配置文件。

链接的参数顺序。 kanban_link(parent_id=..., child_id=...) —— 父级在前。弄混顺序会导致错误的任务被降级为 todo。

如果形状依赖于中间发现，不要预创建整个图。 如果 T3 的结构取决于 T1 和 T2 的发现结果，让 T3 作为一个“综合发现”任务存在，其第一步是读取父级交接内容并规划其余部分。编排器可以生成编排器。

租户继承。 如果在你的环境中设置了 HERMES_TENANT，请在每次 kanban_create 调用中传递 tenant=os.environ.get("HERMES_TENANT")，以便子任务保持在相同的命名空间中。

目标模式卡片（持久工作器）

默认情况下，分派的工作器对其卡片只有一次机会：它执行工作，调用 kanban_complete/kanban_block，然后退出。对于一轮操作很少能完成工作的开放式卡片，传递 goal_mode=True 以将该工作器包裹在 Ralph 风格的目标循环中——这与 /goal 斜杠命令背后的引擎相同：

kanban_create(
    title="Translate the full docs site to French",
    body="Acceptance: every page translated, no English left, links intact.",
    assignee="<translator-profile>",
    goal_mode=True,        # judge re-checks the card after each turn
    goal_max_turns=15,     # optional budget (default 20)
)["task_id"]

其行为方式如下：

• 每次工作器轮次后，辅助评判器会根据卡片的标题 + 正文（视为验收标准）评估工作器的响应。
• 未完成 + 预算仍有剩余 → 工作器在同一会话中继续执行（保留完整上下文——不是全新的重生）。
• 工作器自行调用 kanban_complete/kanban_block → 循环停止，进入正常生命周期。
• 预算耗尽仍未完成 → 卡片被阻塞以待人工审查（粘性阻塞），绝不会静默退出。

何时使用：长期的、多步骤的或“持续进行直到 X 为真”的卡片。何时不使用：廉价的一次性卡片（单个字符串的翻译、快速查找）——评判器开销不值得，且分派器现有的重试/熔断机制已经处理了临时的工作器故障。

将正文编写为明确的验收标准——评判器的效果仅取决于目标文本的质量。“翻译 README”比“将 README 的每个部分翻译成法语；不留任何英语句子”要弱。

恢复卡住的工作器

当工作器配置文件不断崩溃、产生幻觉或因自身错误（通常是：模型错误、缺少技能、凭证损坏）而被阻塞时，看板仪表板会用 ⚠ 徽章标记该任务，并在抽屉中打开一个**恢复（Recovery）**部分。三个主要操作：

1. 收回（Reclaim）（或 hermes kanban reclaim <task_id>）——立即中止正在运行的工作器并将任务重置为 ready。现有的认领 TTL 约为 15 分钟；这是快速退出的路径。
2. 重新分配（Reassign）（或 hermes kanban reassign <task_id> <new-profile> --reclaim）——将任务切换到不同的配置文件（此设置中存在的配置文件），并让分派器使用全新工作器拾取它。
3. 更改配置文件模型——仪表板会打印用于 hermes -p <profile> model 的复制粘贴提示，因为配置文件配置存储在磁盘上；在终端中编辑它，然后执行“收回”以使用新模型重试。

幻觉警告出现在以下任务中：工作器的 kanban_complete(created_cards=[...]) 声明中包含不存在或非该工作器配置文件创建的卡片 ID（网关会阻塞完成），或者自由格式摘要引用了无法解析的 t_<hex> ID（建议性散文扫描，非阻塞）。两者都会生成即使在进行恢复操作后仍然存在的审计事件——痕迹保留用于调试。