$npx -y skills add witt3rd/oh-my-hermes --skill omh-triageMulti-role consensus triage of an issue backlog.
| 1 | # OMH Triage — Consensus Backlog Grooming |
| 2 | |
| 3 | > **v0.1 status:** This skill is **deliberately small**. It ships with two roles (Maintainer, Skeptic) and is being battle-tested before more roles are added. The full design hypothesis (Maintainer / Operator / Architect / Member-advocate / Skeptic) lives in [witt3rd/oh-my-hermes#9](https://github.com/witt3rd/oh-my-hermes/issues/9). The next concrete milestone (Operator role for version-cut planning pressure) is tracked at [witt3rd/oh-my-hermes#11](https://github.com/witt3rd/oh-my-hermes/issues/11). Roles will be added as lived rounds surface real tensions that the current set cannot represent. The discipline here is *learn through use, then expand* — the inverse of authoring all five roles up-front against imagined friction. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - Periodically grooming an issue backlog (default cadence: before each version cut, when ≥10 issues have accumulated since the last pass, or when a major refactor/migration just landed and may have moved issue premises) |
| 8 | - After a fast-moving development arc (multiple migrations or refactors in days/weeks) that may have superseded several open issues |
| 9 | - When the user says: "triage", "groom the backlog", "walk the issues", "what's stale" |
| 10 | |
| 11 | ## When NOT to Use |
| 12 | |
| 13 | - A single ambiguous issue that needs design (use `omh-deep-interview` then `omh-ralplan`) |
| 14 | - A backlog that's never been groomed and has hundreds of issues (do a manual first-pass cull first; this skill is for keeping a curated backlog honest, not for archaeology on a rotted one) |
| 15 | - Closing during active dev (don't mix the two-mode discipline — capture during dev, decide during grooming; see the host project's `docs/triage/PROCESS.md` if it has one) |
| 16 | |
| 17 | ## Prerequisites |
| 18 | |
| 19 | - A target repo with an issue backlog (GitHub Issues; pluggable for other backlogs eventually) |
| 20 | - Optional: a GitHub Project for version + cluster + status targeting (the run will write back to it) |
| 21 | - Optional: prior triage docs under `docs/triage/` for delta-since-last-pass framing |
| 22 | - The `delegate_task` tool must be available |
| 23 | |
| 24 | ## Procedure |
| 25 | |
| 26 | ### Phase 0: Ground-truth pre-flight |
| 27 | |
| 28 | Before dispatching any roles, the orchestrator gathers: |
| 29 | |
| 30 | 1. **Repo HEAD.** Note the commit ref. Verdicts will anchor against this. |
| 31 | 2. **Issue inventory.** `gh issue list --state open --limit <N>`. Note count, label distribution, age distribution. |
| 32 | 3. **Recent migrations / refactors.** Read commit log for the last N weeks. The orchestrator must know what surfaces have moved before dispatching — otherwise the Maintainer will discover this in-flight and waste a round. |
| 33 | 4. **Existing project board state** (if any). Read target version, cluster, status fields for context. |
| 34 | 5. **Prior triage doc** (if any). The most recent `docs/triage/YYYY-MM-DD-*.md` is delta-since-last-pass anchor. |
| 35 | |
| 36 | Phase 0's output is a ~500-word context package that all subagents will receive. Same shape as `omh-ralplan` Phase 0. |
| 37 | |
| 38 | ### Phase 1: Role passes (sequential, parallel where possible) |
| 39 | |
| 40 | **v0.1 ships two roles.** Future versions will add Operator, Architect, Member-advocate. |
| 41 | |
| 42 | #### Step 1 — Maintainer pass |
| 43 | |
| 44 | ``` |
| 45 | delegate_task( |
| 46 | 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>", |
| 47 | context="# Project context\n\n<context-package>\n\n# Inventory\n\n<full issue bodies, not just titles>" |
| 48 | ) |
| 49 | ``` |
| 50 | |
| 51 | The Maintainer's pass is **per-issue**. Output is structured (one block per issue with verdict + anchor + reasoning + close-comment-or-recast-spec). |
| 52 | |
| 53 | #### Step 2 — Skeptic pass (after Maintainer; needs Maintainer's verdicts as input) |
| 54 | |
| 55 | ``` |
| 56 | delegate_task( |
| 57 | 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.", |
| 58 | 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>" |
| 59 | ) |
| 60 | ``` |
| 61 | |
| 62 | The Skeptic only reviews issues the Maintainer marked live or recast. Stale/out-of-scope are already moving to close; double-pressure on them wastes the role's attention. |
| 63 | |
| 64 | #### Step 3 — Orchestrator distillation |
| 65 | |
| 66 | The orchestrator combines Maintainer + Skeptic verdicts. **The matrix below is authoritative** — every Maintainer × Skeptic combination resolves to a specific disposition. Combinations not enumerated here are the only cases that escalate to user as a true conflict. |
| 67 | |
| 68 | The Maintainer verdict `partial-stale` (issue contains multiple sub-claims; some stale, some live) is treated identically to `recast` for m |