shunk031-herdr-meta-orchestrate

说明

阅读此 SKILL.md 后，请说：🪆 I read shunk031-herdr-meta-orchestrate.

协调 Herdr 会话

请将此技能与 shunk031-herdr-orchestrate-workers 技能配合使用，并在开始工作前阅读两者。此技能负责跟踪顶层协调器、请求状态并转发消息；shunk031-herdr-orchestrate-workers 技能负责启动和管理你自己的工作线程，以执行具体任务。

flowchart TD
    Meta["Meta-orchestrator<br/>shunk031-herdr-meta-orchestrate skill"]
    MetaWorkers["Meta's name-prefixed workers<br/>shunk031-herdr-orchestrate-workers skill"]
    LocalRoot["Local root orchestrator<br/>overseen by shunk031-herdr-meta-orchestrate skill"]
    LocalWorkers["Local root's workers<br/>managed by shunk031-herdr-orchestrate-workers skill"]
    RemoteRoot["Saved-machine root orchestrator<br/>overseen by shunk031-herdr-meta-orchestrate skill"]
    RemoteWorkers["Root's workers<br/>managed by shunk031-herdr-orchestrate-workers skill"]

    Meta --> MetaWorkers
    Meta --> LocalRoot --> LocalWorkers
    Meta --> RemoteRoot --> RemoteWorkers

执行巡查

每次开始一次性巡查或获批的定期巡查时，都使用随附的只读脚本。通过 HERDR_PATROL_ROOTS_JSON 提供已验证的顶层 Agent：

export HERDR_PATROL_ROOTS_JSON='[{"machine":null,"agent":"meta"},{"machine":"saved-machine-label","agent":"root"}]'
~/.agents/skills/shunk031-herdr-meta-orchestrate/scripts/herdr-meta-patrol.sh

每个数组项都包含 machine 和 agent：本地服务使用 null，远程服务使用准确的已启用已保存机器标签；agent 则填写 Agent 的实时名称。只包含你已在下文核实了角色和层级关系的顶层 Agent。脚本会列出本地 Agent 和每台已启用已保存机器上的 Agent，然后报告受阻的 Agent、非 null 的 .tokens.inbox 值，以及非空的顶层输入行。它会将窗格输出作为 ANSI 读取，在组合参数和重置之间跟踪暗淡的 SGR 状态，并且只统计提示符字符之后的非暗淡文本。所需的 shunk031-herdr-orchestrate-workers 技能中随附了共享解析器。即使某台已保存机器不可用，巡查仍会继续。

输出为 JSON Lines，每项发现对应一个对象；没有输出表示没有发现。发现项包括需要关注的 Agent、被占用或无法读取的顶层输入、不可用的服务以及无效的顶层目标。对于这些标准检查，请使用脚本，而不要临时自行重建检查流程。转发任何内容前，请先在相应窗格或记录稿中检查报告的收件箱条目和角色不明确的顶层 Agent。

查找并询问顶层协调器

使用 Herdr 命令前，请先阅读 herdr 技能。先运行随附的巡查脚本，刷新本地和已启用已保存机器上的 Agent 状态。要核实角色和层级关系，或诊断发现项，请使用 herdr agent list、herdr machine list --json 和 herdr --machine <label-or-id> agent list 检查相关服务。

分别盘点每个 Herdr 服务。通过准确的窗格或会话标识确认当前会话，并且只排除该会话。将列出的其他所有 Agent 都视为候选对象，即使它没有工作线程也是如此。在每个服务中，最长匹配的 <agent-name>- 前缀只能作为可能存在父子关系的线索；在将候选对象排除为工作线程或嵌套协调器之前，请根据窗格或记录稿证据核实其层级关系和角色。切勿根据另一台服务上的名称推断层级关系。纳入已核实为顶层协调器的候选对象，无论其是否有工作线程；角色或层级关系不明确时，应报告为未核实，不要猜测。不要单独盘点各个 worktree 工作线程。

如果远程 Agent 列表因 Herdr 服务不支持机器 API 转发而失败，请检查 herdr machine status <label-or-id> --json 和报告的服务版本。将该机器的盘点结果报告为不可用；不要猜测其 Agent 或进度。

转发回复前，请通过最新读取结果或记录稿进行核实。恢复会话或在其他位置打开会话时，Agent 名称可能会移至其他窗格，因此请根据窗格 ID 和记录稿重新识别实时 Agent，不要依赖过期名称。

仅发送到空的根输入框

每次从 meta 中继到 root 之前，都要先在带引号的变量中构建完整消息，并使用必需的 shunk031-herdr-orchestrate-workers 技能中附带的 helper：

~/.agents/skills/shunk031-herdr-orchestrate-workers/scripts/herdr-agent-prompt-if-input-empty.sh <root> "$message"

helper 会通过 herdr agent get 确定 root 窗格，并使用 herdr pane read --source visible --format ansi 读取内容，同时仍以 herdr agent prompt 作为传输方式。它会检查最后一行包含 ❯ 或 › 的行，规范化 NBSP 并去除尾随 CR，同时移除 CSI 序列并跟踪 SGR 暗淡文本范围。只有提示符符号之后非暗淡、非空白的文本才算已占用。如果读取失败或无法明确判断该行，则等待 30 秒后重新检查，最多检查五次；如果仍然已占用或无法明确判断，则不要发送，并报告完整中继消息未送达。报告、问题或用户的回答也不得绕过此 helper。

精确中继

逐字引用每位协调者的回复，并注明其来源。为中继内容添加标签 Transport note from meta: Verbatim from <source> follows.，在转发文本前后添加明确的起止标记，并将 meta 自己的说明放在这些标记之外。将用户的指示原样传给负责处理该指示的协调者，并一并传递其所回答的问题。

初次派发时，如果工作者无法向 meta 发送提示，则要求其在回合结束时给出最终报告，格式为 STATUS <worker-name>:、BLOCKED <worker-name>: 或 DONE <worker-name>:；meta 会读取对话记录并进行中继。对于审查结果，要求报告第一行包含结论和完整 PR URL（例如 ACCEPT <PR URL> 或 REJECT <PR URL>）；详情放在后面。对于较长的草稿或指示，要求工作者将完整文本以 Markdown 格式写入 /tmp/<file>.md，并且只回复 WROTE <path>。如果文件位于同一台机器上，则直接读取；如果通过 SSH 传输，则传输 Base64 编码的字节，在目标位置解码，并在逐字中继文本前比较源端和目标端的 SHA-256 哈希值。传输时不要使用 fold -w，因为它会插入换行符。

只有明确来自用户的回复，才能将决定视为用户的回答；中继时，须将其标记为用户的回答，注明其回答的问题，并逐字保留用户的措辞。将你自己的建议标记为 meta 的判断；如果工作者的报告将该判断归于用户，则予以纠正。

如果无法确定 root 输入框中显示的文本是用户已发送的内容还是尚未发送的建议，则将其视为未经确认。询问用户；在用户确认之前，不要将其作为用户指示执行。

跟进与巡查

每次向某个根节点发送消息或提问后，都要设置回复截止时间，并在本地通过 herdr agent wait <root> --timeout <milliseconds> & 启动有时限的后台等待；对于已保存的机器，则通过 herdr --machine <label-or-id> agent wait <root> --timeout <milliseconds> & 启动。遵循 shunk031-herdr-orchestrate-workers 技能中的等待生命周期，不要重复实现其机制。等待结束后，重新读取根节点的窗格或记录，并指出需要用户作出的任何决定，或根节点陷入停滞的证据。如果预期的结论未在截止时间前到达，则在输入为空时通过受保护的发送器追问一次，然后再启动一次有时限的等待。如果仍未收到结论，则报告这一情况，并将结果标记为未经验证；绝不要无限期等待结论。如果根节点因连接问题无法回复，则报告连接问题，并将其当前状态标记为未经验证；连接恢复后，再请求最新状态。

启动定期检查前，先请用户批准，并商定检查间隔。对于初次检查和每次获批的定期检查，都使用当前根节点配置重新运行捆绑的巡查工具，并检查其 JSON Lines 结果。在将收件箱条目作为根节点的请求转达前，先在该根节点的窗格或记录中核实；Agent 列表可能包含同一台机器上其他会话的条目。对于用户尚未在其收件箱或聊天中看到的请求，应逐字转达，并将任何解释单独说明。

重启与工具检查

重启 Herdr 服务或根节点会话前，将每个受影响根节点的启动命令、参数和环境配置记录在适当的私有运维笔记中，不要复制机密值。重启后，核实每个根节点都在使用记录的设置；仅恢复会话并不能证明这一点。

将通过版本管理器垫片执行的命令视为可能安装或更改工具，即使它们只是查询版本信息也是如此。进行检查时，应使用不会触发安装的已安装工具列表，或其他来源。

委派任务工作

用户明确同意后，由你亲自处理清单、状态请求、消息转发、协调、分析、判断和窗格焦点。对于要做什么以及要告诉用户或协调者什么，始终在元层面作出决定。将其他所有具体实施或操作（包括提交、更改配置、回复对话框和删除）委派给使用你自己的名称前缀命名的工作者，并通过 shunk031-herdr-orchestrate-workers 技能执行；不要亲自执行这些操作。明确说明每位工作者的目标和授权范围。编写 Codex 任务提示词时，遵循该技能的生命周期以及 shunk031-codex-worker-prompting 技能。模型和凭据选择应放在引用的启动指南中，而不是这个公开技能中。

让工作者起草或审阅面向读者的 README、文档、拉取请求正文或报告时，应要求检查是否存在不必要的安抚性表述，例如告诉读者不必做什么或担心什么（例如：“无需安装。”）。要求审阅者统计并报告每处此类表述，包括零处。

每项用户授权都只能用于指定的目标和次数。如果某项派发会影响超出用户批准范围的目标数，则停止操作并报告不匹配。未经用户明确许可，不得为相应目标还原、切换检出、贮藏、重置或丢弃未提交的更改。

聚焦窗格前先询问

如果某个窗格需要用户查看或输入，请询问：“要我聚焦该窗格吗？”等待用户明确答复“是”。然后仅使用 herdr workspace focus 和 herdr tab focus 聚焦已确认的工作区和标签页；如果目标发生变化，请再次询问。窗格控制和敏感输入处理请遵循 herdr 技能。

根据 shunk031-herdr-tab-status 技能维护你自己的标签页状态。herdr 技能负责 CLI 操作、ID、窗格控制和远程机器安全；shunk031-herdr-orchestrate-workers 技能负责工作者调度、生命周期和报告。