用途：定期整理 issue 待办列表，默认节奏为每次版本切分前、自上次整理后累积≥10 个 issue，或重大重构/迁移刚落地可能改变 issue 前提时。也可在快速开发（多次迁移或重构）后清理已被取代的 issue，或用户说出 triage、groom the backlog、walk the issues、what's stale 时触发。不适用于：单个需要设计的模糊 issue（改用 omh-deep-interview 再 omh-ralplan）；从未整理、数量上百的 backlog（先手动初筛）；开发进行中关闭 issue（捕获与决策分开）。
主要能力：Phase 0 先做地面真值预检，收集仓库 HEAD、issue 清单（gh issue list --state open --limit <N>）、近期迁移/重构、项目看板状态、上次整理文档，形成约500字上下文包。Phase 1 依次执行两个角色：Maintainer 逐个核对 issue 与当前代码，产出 stale/recast/live/partial-stale/out-of-scope 裁决及代码锚点；Skeptic 仅评审 live、recast 项，给出 keep/drop/dedup/refile-smaller/wait-for-recurrence。Phase 2 由编排者按裁决矩阵汇总，输出 docs/triage/YYYY-MM-DD-<descriptor>.md、处置执行计划与看板更新，默认只暂存不执行。Phase 3 经用户批准后才发布评论、关闭、提交改写与更新看板。
使用方式：需可用 delegate_task 工具；目标仓库有 GitHub Issues（理论上可插拔其他待办系统）；可选 GitHub Project 与既有 triage 文档。角色分派用 delegate_task，派发目标带 [omh-role:triage-maintainer] / [omh-role:triage-skeptic] 标记。关闭前用 --comment "$(cat /tmp/closeN.md)" 循环执行，避免多段正文被静默失败。
限制：v0.1 仅两个角色；Operator、Architect、Member-advocate 计划在 v0.2+ 添加，尚无实现；矩阵之外或角色返回 needs lived signal 等未枚举值才升级给用户；缺少地面真值预检会造成重复劳动。具体依赖版本、安装方式与收费信息暂未提供。