omh-triage-driver

OMH 分诊驱动器——驱动一轮分诊

**v0.1 状态：**与工作者技能（omh-triage）一样，这个调度器的操作手册刻意保持精简。陷阱会在实际运行中逐渐积累。omh-ralplan-driver 技能是结构上的范本——只有在多次实际运行逐一暴露出各种失败模式后，它才扩展到 25 个编号陷阱。这个技能从 T1–T6 起步，逐步完善。

何时你是编排者

如果你正将 omh-triage 分派到积压事项上，并打算在实际议题中落实裁定（关闭、重定向、指定版本），你就是编排者。

如果你只是把 omh-triage 当作实验，想看看该技能会产出什么（没有执行意图），那你就不是编排者。做实验时，可以跳过用户签字确认环节，只观察结果——但要在任何输出文档中将本次运行标记为探索性。

运行前纪律

调用 omh-triage 之前：

审查积压状态

1. **议题数量。**如果未关闭议题少于 10 个，你可能不需要分诊；手动决定即可。如果未关闭议题超过 100 个，积压已经腐化；调用前先手动进行一轮初筛。
2. **距上次梳理的时间。**如果不到 2 周，且没有合入重大重构，可能不值得进行一轮分诊。
3. 项目看板状态（如有）。“不会发布”或暂存列中的卡片应由一轮分诊清理，而不是任其不断累积。
4. **近期迁移或重构。**这是运行前最关键的检查——*自议题创建以来，有哪些表层发生了变化？*如果答案是“很多”，分诊的杠杆作用很大。如果答案是“没有”，分诊的杠杆作用就很小。

审查触发原因

本次运行的实际原因是什么？

• “即将发布 vN+1，想了解范围内有哪些内容”→ 分诊将为版本发布规划提供依据。输出应针对项目的版本字段。
• “刚完成一次重大迁移，若干议题可能已过时”→ 分诊是一次清理。输出大多是关闭议题。
• “积压感觉太重，想精简一下”→ 怀疑者的压力占主导；维护者提供支持。相应地明确目标。
• “定期维护，没有具体动因”→ 优先级较低；可以考虑等出现触发原因后再做。

触发原因会影响你对各角色输出的权重分配。清理类运行侧重维护者；精简类运行侧重怀疑者。

审查宿主项目的纪律

宿主项目是否具备：

• 记录双模式规范（快速创建与梳理）的 docs/triage/PROCESS.md？
• 带有目标版本和集群字段的 GitHub Project？
• 可供对比的既往分诊文档？

如果没有，建议先创建这些内容——omh-triage 会生成带日期的文档并更新项目看板；如果没有可写入这些内容的基础设施，输出就会付诸东流。

调度器在运行期间的职责

第 0 阶段（收集上下文）期间

由你编写上下文包，而不是由子 Agent 编写。上下文包会影响两个子 Agent 的工作；如果写得不对，会浪费双方的工作。

上下文包必须包含：

• 仓库 HEAD 引用（作为维护者审核的基准）
• 近期迁移／重构清单及简要说明（避免维护者重新推导）
• 议题数量、标签分布和年龄分布
• 既往分诊文档摘要（如有），具体说明：哪些裁定已落实，哪些事项已延期
• 触发原因的定位（清理、精简或维护）

如果上下文包超过约 1000 个词，就太臃肿了。目标长度约为 500 词。

阶段 1 期间（角色轮次）

先运行 Maintainer；只有在 Maintainer 提交实时结果并重新审视后，才运行 Skeptic。不要让两者从头并行运行——Skeptic 需要 Maintainer 的判定来明确审查内容。

留意以下失误模式（每个实际发生时都记为一个带编号的陷阱）：

• T1 — Maintainer 声称问题已“过时”，却没有提交引用。 驳回并要求提供依据。“已在最近一次迁移中完成”不是有效依据；“已在 v6 中完成（提交 c49abbf）”才是。
• T2 — Skeptic 审查过时问题。 这是浪费轮次。技能正文要求跳过这些问题，但如果调度器把错误的问题清单交给 Skeptic，就会发生这种情况。
• T3 — 子 Agent 输出一段平铺的叙述，而不是按问题分块。 技能的输出格式有其结构化的理由——提炼依赖于按问题解析。驳回并要求提供结构化输出。

阶段 2 期间（提炼）

你——编排者——要根据技能中的判定组合矩阵生成决议表。冲突应交由用户处理，不要自动解决。要具体指出哪些问题存在冲突；只说“存在一些冲突”还不够。

如果本轮没有冲突，值得记录下来。这可能说明本轮的角色压力彼此契合（好事），也可能说明各角色施压不够充分（坏事）。连续几轮都没有冲突后，就该加入第三个角色了。

阶段 3 期间（执行）

须经用户批准。执行关闭、重新审视和看板更新。实际关闭操作使用 /tmp/closeN.md + shell 循环惯用法（不要在 execute_code 中使用 terminal()——多段引用内容在那里会静默失败；这是在 janus 第 1 轮中学到的）。

执行后，撰写轮次文档。文档要说明你做了什么、推迟了什么，以及本轮带来了哪些经验——如果后续轮次证实这些经验成立，可能需要将其纳入 PROCESS.md 或本技能。

陷阱（v0.1）

T1 — 跳过事实核查预检

调度器最能发挥作用的阶段是阶段 0。事实依据不准确的运行会产生过时判定，而这些判定因为来自多角色共识，看起来很有权威性。应遵守的做法：调度任何人之前，花 10 分钟梳理近期迁移。

T2 — 在运行前撰写分诊文档

不要先把自己的判定写进文档，再运行 omh-triage 来“验证”。各角色的任务是发现调度器遗漏的内容；如果调度器已经做出决定，各角色就只是走过场。应根据运行输出撰写文档，而不是让运行结果迎合文档。

T3 — 任由运行范围扩大

整理轮次的范围是明确的：运行时仍未关闭的问题。如果某个角色提出“我们还应该重新设计 X”，那属于单独的 ralplan，不属于分诊范围。把它记在轮次文档的“推迟处理”部分；不要试图在当前循环中处理。

T4 — 不重视待关闭问题

关闭是持久性的。错误关闭的问题，比错误保留的问题更难恢复。发布前要阅读每条指针评论，即使角色的判定看起来很明确。Maintainer 对问题“过时”的判定需要你确认，而不是盲目照办。

T5 — 把冲突当作问题提出，而不是给出决策

角色意见不一致时，你的提炼结果应当给用户一个具体的决策问题，而不是笼统地说“这 N 个问题存在一些分歧”。每项冲突都应这样表述：“Maintainer 基于理由 A 得出 X；Skeptic 基于理由 B 得出 Y；我的建议是 Z。”然后再提问。（参见 omh-ralplan-driver P25——重视质疑而非顺从。）

T6 — 运行过于频繁

整理不是日常工作。如果你发现自己每周都在运行 omh-triage，那底层问题就是提交的问题数量超过团队愿意处理的数量；解决办法在上游（提高问题提交规范、缩小积压、减少新问题），而不是增加分诊次数。

模板

• plugins/omh/skills/omh-triage/references/triage-doc-template.md — 轮次文档的结构
• plugins/omh/skills/omh-triage/references/orchestrator-review-template.md — 由你进行的执行前审查

配套工具

• omh-triage — 工作技能
• omh-ralplan-driver — 本流程遵循的结构模型
• 宿主项目的 docs/triage/PROCESS.md（如果存在），用于定义分诊所遵循的双模式快速记录／梳理规范