omh-triage

OMH 分类整理——通过共识整理待办事项

v0.1 状态：此技能刻意保持精简。目前提供两个角色（维护者、质疑者），正在接受实战检验，之后再添加更多角色。完整的设计假设（维护者 / 操作者 / 架构师 / 成员倡导者 / 质疑者）见 witt3rd/oh-my-hermes#9。下一个具体里程碑（用于版本发布规划压力测试的操作者角色）已在 witt3rd/oh-my-hermes#11 中跟踪。只有当实际进行的轮次暴露出当前角色集无法呈现的真实矛盾时，才会添加角色。这里的原则是在使用中学习，然后扩展——这与一开始就针对想象中的摩擦预先编写全部五个角色正好相反。

适用场景

• 定期整理议题待办列表（默认频率：每次发布版本前、上次整理后累计 ≥10 个议题时，或重大重构 / 迁移刚完成且可能改变议题前提时）
• 经历快速推进的开发阶段（数天 / 数周内进行了多次迁移或重构）后，这些变更可能已使多个未解决议题失效
• 用户说：“分类整理”“整理待办列表”“过一遍议题”“哪些过时了”

不适用场景

• 需要设计讨论的单个模糊议题（使用 omh-deep-interview，然后使用 omh-ralplan）
• 从未整理过、且包含数百个议题的待办列表（先手动进行首次筛选；此技能用于确保经过筛选的待办列表信息准确，而不是考古已腐朽的列表）
• 开发正在进行时关闭议题（不要混淆两种工作模式——开发期间记录，整理期间决策；如果宿主项目有 docs/triage/PROCESS.md，请参阅该文件）

前置条件

• 目标仓库有议题待办列表（GitHub Issues；以后可扩展支持其他待办列表）
• 可选：用于指定版本 + 分组 + 状态的 GitHub Project（本次运行会将结果写回其中）
• 可选：docs/triage/ 下有此前的分类整理文档，用于对比自上次整理以来的变化
• 必须能够使用 delegate_task 工具

流程

阶段 0：核实实际情况

分派任何角色前，编排器应收集以下信息：

1. **仓库 HEAD。**记录提交引用。所有判定均以此为依据。
2. **议题清单。**运行 gh issue list --state open --limit <N>。记录数量、标签分布和时间分布。
3. **近期迁移 / 重构。**阅读最近 N 周的提交日志。编排器必须在分派前了解哪些方面发生了变化，否则维护者会在处理中才发现这些变化，白白浪费一轮。
4. 现有项目看板状态（如有）。读取目标版本、分组和状态字段，作为背景信息。
5. 此前的分类整理文档（如有）。最新的 docs/triage/YYYY-MM-DD-*.md 是对比自上次整理以来变化的基准。

阶段 0 的输出是一份约 500 词的背景资料包，所有子 Agent 都会收到。结构与 omh-ralplan 阶段 0 相同。

阶段 1：角色审查（依次进行，尽可能并行）

**v0.1 提供两个角色。**未来版本会添加操作者、架构师和成员倡导者。

步骤 1——维护者审查

delegate_task(
    goal="[omh-role:triage-maintainer] Vet each issue in the attached inventory against current code. Produce a per-issue verdict (stale/recast/live/partial-stale/out-of-scope) with code-anchored reasoning. Repo HEAD: <ref>. Inventory: <list>",
    context="# Project context\n\n<context-package>\n\n# Inventory\n\n<full issue bodies, not just titles>"
)

维护者的审查以单个议题为单位。输出采用结构化格式（每个议题一个区块，包含判定 + 依据 + 推理 + 关闭评论或重拟规格）。

步骤 2——质疑者审查（维护者审查后进行；需以维护者的判定为输入）

delegate_task(
    goal="[omh-role:triage-skeptic] For each LIVE issue from the Maintainer pass, apply skeptical pressure: keep/drop/dedup/refile-smaller/wait-for-recurrence. Stale/out-of-scope issues do not need skeptical review.",
    context="# Project context\n\n<context-package>\n\n# Maintainer verdicts\n\n<Maintainer's structured output>\n\n# Full inventory (for cross-reference)\n\n<full issue bodies>"
)

质疑者只审查维护者标记为有效或需重拟的议题。过时 / 超出范围的议题已经进入关闭流程；对它们施加双重压力会浪费该角色的注意力。

步骤 3 — 协调器提炼

协调器综合维护者 + 怀疑者的判定。下方矩阵具有权威性——每种维护者 × 怀疑者组合都会对应一个特定处置方式。只有这里未列出的组合才会作为真正的冲突升级给用户。

维护者判定 partial-stale（问题包含多个子主张；部分已过时，部分仍有效）在矩阵中与 recast 完全相同——两者都表示“正文需要大幅修改，可能需要进行大量改动”。维护者的输出仍应区分两者，以便重拟说明明确指出哪些子主张已过时、哪些仍有效，但处置方式相同。

维护者	怀疑者	解决后的处置方式
stale	（未运行）	关闭 — 维护者添加指向评论
out-of-scope	（未运行）	关闭 — 指明重新提交目标
recast / partial-stale	keep	重拟正文，保持开启
recast / partial-stale	drop / wait-for-recurrence	关闭 — 怀疑者添加指向评论（正文需要修改，且根本摩擦可能并非关键因素；综合判定为“不值得修改”）
recast / partial-stale	dedup	关闭 + 在覆盖此问题的问题下评论
recast / partial-stale	refile-smaller	关闭 + 以较小的问题重新开启
live	keep	保持有效
live	drop / wait-for-recurrence	关闭 — 怀疑者添加指向评论
live	dedup	关闭 + 在覆盖此问题的问题下评论
live	refile-smaller	关闭 + 以较小的问题重新开启

该矩阵涵盖了此技能（v0.1）中的所有判定类型。未来版本新增角色或判定类型时，矩阵也会扩展；只有当新的组合没有对应的解决方式时，才会出现冲突。

升级情形（在 v0.1 中很少见）：如果怀疑者返回 needs lived signal（当无法确定判定时，该角色的兜底选项）——或角色目录中未列出的任何其他未解决值——这就是真正需要升级的情况。协调器会将这些情况作为具体的决策问题提交给用户。协调器的职责是提炼，而不是在矩阵无法解决时替用户做决定。

阶段 2：输出

协调器会生成：

1. 分诊文档，路径为 docs/triage/YYYY-MM-DD-<descriptor>.md（位于宿主仓库中，而非此技能仓库中），并使用宿主项目的模板。如果没有模板，则使用 references/triage-doc-template.md 中记录的结构。
2. 判定执行计划——关闭项列表（正文文件暂存于 /tmp/closeN.md）、重拟项（附拟议的正文差异）以及重新提交较小问题的草稿。
3. 项目看板更新（如果配置了项目）——目标版本变更、集群更新、状态变更。

默认情况下，协调器只暂存，不执行。用户签字确认环节位于阶段 2 与执行之间。参见 references/orchestrator-review-template.md。

阶段 3：执行（需用户批准）

用户批准后：

1. 发布指向评论，并关闭过时或已舍弃的问题
2. 发布重拟 PR（或附有拟议正文修改的评论）
3. 更新项目看板字段
4. 以适当的署名提交分诊文档

v0.1 中的角色

角色	参考文档	关注重点
分诊维护者	references/role-triage-maintainer.md	以代码为依据的事实：前提是否仍有效？
分诊怀疑者	references/role-triage-skeptic.md	精简筛选：这个问题值得占据一个名额吗？

计划在 v0.2+ 中推出的角色（witt3rd/oh-my-hermes#9）：

• 运营者 — 版本规划：最小且有充分依据的 vN+1
• 架构师 — 跨领域分析：哪些问题是同一根源的表象
• 成员倡导者 — 亲身体验：用户/负责人/个体当下受到什么影响

当实际分诊轮次暴露出当前两个角色无法表达的矛盾时，才会添加这些角色。不要在缺乏证据时提前编写这些角色。

输出质量标准

一次运行满足以下条件即告完成：

1. 每个未关闭的问题都有 Maintainer 的裁定（没有跳过任何问题）
2. 每个保留或重拟的问题都有 Skeptic 的裁定
3. 每个过时或舍弃的问题都有一条可发布的指向性评论
4. 每个重拟的问题都有具体的正文修改方案（而不是“重写正文”）
5. 冲突会升级给用户，而不是悄悄解决
6. 分诊文档会列明本轮未处理的内容（延期工作）

注意事项（v0.1，后续会扩充）

T1 — 没有真实依据的 Phase 0，就不要派遣 Maintainer

Maintainer 的职责是以当前代码为依据。如果协调者尚未梳理近期迁移或重构，Maintainer 就会在执行过程中发现它们，浪费精力重新推导 Phase 0 本应提供的内容。

T2 — Skeptic 只审核保留和重拟的问题

Maintainer 标记为过时或超出范围的问题已经在走关闭流程。把这些问题发给 Skeptic 只会制造噪声（Skeptic 会对过时问题说“舍弃”，毫无帮助）。

T3 — 默认暂存，而非执行

分诊关闭操作会在问题跟踪器上产生持久影响。始终将关闭操作暂存为 /tmp/closeN.md 中的正文文件，并让用户在执行实际关闭命令前批准。批准后执行关闭操作的技能应在 shell 中循环，并使用 --comment "$(cat /tmp/closeN.md)"（通过 execute_code 中的 terminal() 传递多段落引用正文会静默失败——这是 janus 第 1 轮的教训）。

T4 — 按矩阵裁定；仅未列明的情况才升级

Phase 1 Step 3 中的裁定组合矩阵具有权威性——live + drop 的裁定是“关闭 — 由 Skeptic 发布指向性评论”，而不是“提交用户裁决”。矩阵体现了我们审慎作出的判断：“Maintainer 认为问题仍然存在，Skeptic 认为应该舍弃”意味着问题确实存在，但不值得占用它所消耗的名额；正确的处理方式是关闭问题，并附上清晰的指向性评论，邀请用户在问题再次出现时重新提交，而不是要求用户作出决定。

真正需要升级的情况包括：Skeptic 给出 needs lived signal（退出机制），Maintainer 给出 needs investigation（退出机制），或未来某个角色的裁定产生了矩阵未列明的组合。v0.1 中这类情况很少见，应以具体的决策问题提交给用户，而不是笼统地说“存在一些冲突”。

如果协调者根据自身标准重新审视裁定后得出了不同结论，也可以覆盖矩阵，应用于个别问题；但这是协调者的判断，而非矩阵冲突。请在协调者评审中明确记录覆盖操作（omh-ralplan-driver P25 — 此处同样应保持怀疑，而非盲目遵从）。

T5 — 每轮都要产出一份持久文档

位于 docs/triage/YYYY-MM-DD-*.md 下的分诊文档是本轮的审计记录。它会写明作出了哪些决定、哪些工作被延期，以及本轮有哪些经验教训。没有文档，就等于没有进行这一轮。

T6 — 抵制预先补齐缺失角色的压力

此技能特意保持在 v0.1。OMH#9 设计中定义了五种角色；目前只实现了两种。在实际运行暴露出真实矛盾之前就加入 Operator / Architect / Member-advocate，正是“想象中的摩擦”这种失误模式。等待证据。

配合使用

• omh-triage-driver — 协调者的操作手册（何时调用、如何推进、良好输出的样子）
• omh-ralplan-driver — 设计层的类似技能；纪律模式相近
• omh-deep-interview — 用于需要先澄清、才能进行分诊判断的模糊问题

另请参阅

• witt3rd/oh-my-hermes#9 — 设计跟踪问题
• references/role-triage-maintainer.md
• references/role-triage-skeptic.md