# Omh Triage Driver > Drive omh-triage: when to invoke, how to run rounds. - Skill: `witt3rd/omh-triage-driver` (Agent Skill) - Install (CLI): `npx skillmds@latest add witt3rd/omh-triage-driver` - Raw SKILL.md: https://api.skillmd.com/api/skills/witt3rd/omh-triage-driver/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: witt3rd (https://skillmd.com/u/witt3rd) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/witt3rd/omh-triage-driver --- # OMH Triage Driver — Driving a Triage Run > **v0.1 status:** Like the worker skill (`omh-triage`), this dispatcher's playbook is deliberately small. Pitfalls accumulate through lived rounds. The `omh-ralplan-driver` skill is the structural model — that one shipped to 25 numbered pitfalls only after multiple real runs surfaced each failure mode. This one starts at T1–T6 and grows. ## When You Are the Orchestrator You are the orchestrator if you are dispatching `omh-triage` against a backlog and intending to land verdicts (closures, recasts, version targeting) on real issues. You are not the orchestrator if you are running `omh-triage` as an experiment to see what the skill produces (no execution intent). For experiments, skip the user sign-off gate and just observe — but mark the run as exploratory in any output doc. ## Pre-flight Discipline Before invoking `omh-triage`: ### Audit the backlog state 1. **Issue count.** If <10 open issues, you probably don't need triage; just decide manually. If >100 open issues, the backlog has rotted; do a manual first-pass cull before invoking. 2. **Time since last grooming.** If <2 weeks AND no major refactor landed, may not be worth a round. 3. **Project board state** (if any). Cards in "Won't ship" / staging columns should be drained by a triage round, not left to accumulate. 4. **Recent migrations or refactors.** This is the load-bearing pre-flight check — *what surfaces have moved since issues were filed?* If the answer is "many," triage is high-leverage. If the answer is "none," triage is low-leverage. ### Audit the **trigger** What's the actual reason for this run? - "About to cut version vN+1, want to know what's in scope" → triage will inform version-cut planning. Output should target the project's version field. - "Just shipped a major migration, several issues may be stale" → triage is a cleanup pass. Output is mostly closures. - "Backlog feels heavy, want to prune" → Skeptic's pressure dominates; Maintainer is supporting. Frame the goal accordingly. - "Periodic hygiene, no specific motivator" → low-priority; consider deferring until a triggering reason exists. The trigger shapes how you weight the role outputs. A cleanup-pass run weights Maintainer; a pruning run weights Skeptic. ### Audit the host project's discipline Does the host project have: - A `docs/triage/PROCESS.md` documenting two-mode discipline (quick-file vs grooming)? - A GitHub Project with target-version + cluster fields? - A prior triage doc to delta against? If not, propose authoring these first — `omh-triage` produces dated docs and project-board updates; if there's no infrastructure to write them into, the output evaporates. ## The dispatcher's job during the run ### During Phase 0 (context gathering) You author the context package, not a subagent. The package shapes both subagents' work; getting it wrong wastes both passes. The package must include: - Repo HEAD ref (the anchor for Maintainer's vetting) - List of recent migrations / refactors with brief description (so Maintainer doesn't re-derive) - Issue count + label distribution + age distribution - Prior triage doc summary (if any), specifically: what verdicts landed, what was deferred - The trigger framing (cleanup vs pruning vs hygiene) If the package is over ~1000 words, it's bloated. ~500 is the target. ### During Phase 1 (role passes) Maintainer first; Skeptic only on Maintainer's live + recast output. Don't run them parallel-from-scratch — the Skeptic needs Maintainer's verdicts to know what to review. Watch for these failure modes (each becomes a numbered pitfall as it's lived): - **T1 — Maintainer claims "stale" without a commit ref.** Reject and request anchor. "Done in a recent migration" is not a valid anchor; "Done in v6 (commit `c49abbf`)" is. - **T2 — Skeptic reviews stale issues.** A waste-of-pass. The skill body says skip them, but if the dispatcher passes the wrong inventory to Skeptic, this happens. - **T3 — Subagent produces a flat narrative instead of per-issue blocks.** The skill's output format is structured for a reason — distillation depends on per-issue parsing. Reject and request structured output. ### During Phase 2 (distillation) You — the orchestrator — produce the resolution table per the skill's verdict-combination matrix. Conflicts go to user, not auto-resolved. Be specific about *which* issues are conflicts; "there are some conflicts" is not enough. If the round produced **no conflicts**, that's worth noting. Either the role pressures are well-aligned this round (good) or the roles haven't pressed hard enough (bad). After several rounds with zero conflicts, it's time to add a third role. ### During Phase 3 (execution) User-gated. Execute closures, recasts, board updates. Use the `/tmp/closeN.md` + shell-loop idiom for the actual close commands (not `terminal()` from `execute_code` — multi-paragraph quoted bodies fail silently there; learned in janus round 1). After execution, write the round doc. The doc names what you did, what you deferred, and what the round *taught* — lessons that may want to fold back into PROCESS.md or this skill if subsequent rounds confirm them. ## Pitfalls (v0.1) ### T1 — Skipping ground-truth pre-flight The dispatcher's biggest leverage is Phase 0. A run with bad ground truth produces stale verdicts that look authoritative because they came from a multi-role consensus. The discipline: spend 10 minutes mapping recent migrations *before* dispatching anyone. ### T2 — Authoring the triage doc before the run Don't write your verdicts into the doc and then run `omh-triage` to "validate" them. The roles' job is to surface what the dispatcher missed; if the dispatcher already decided, the roles are theater. Write the doc *from* the run output, not *toward* it. ### T3 — Letting the run grow scope A grooming round has a defined scope: the open issues at the time of the run. If a role surfaces "we should also redesign X" — that's a separate ralplan, not part of triage. Note it in the round doc's "deferred" section; don't try to handle it in-loop. ### T4 — Treating the close pile as low-attention Closures are durable. A wrongly-closed issue is much harder to recover than a wrongly-kept one. Read every pointer-comment before posting, even when the role's verdict feels clear. The Maintainer's "stale" verdict is your verdict to ratify, not to rubber-stamp. ### T5 — Conflicts presented as questions, not as decisions When the roles disagree, your distillation should produce a **specific decision question for the user** — not a generic "there's some disagreement on these N issues." Frame each conflict as: "Maintainer says X for reason A; Skeptic says Y for reason B; my recommendation is Z." Then ask. (See `omh-ralplan-driver` P25 — skepticism over deference.) ### T6 — Running too often Grooming is not a daily activity. If you find yourself dispatching `omh-triage` weekly, the underlying problem is more issues are filed than the team is willing to act on; the fix is upstream (better filing discipline, smaller backlog, fewer new issues), not more triage. ## Templates - `plugins/omh/skills/omh-triage/references/triage-doc-template.md` — structure for the round doc - `plugins/omh/skills/omh-triage/references/orchestrator-review-template.md` — pre-execution review by you ## Pairs With - `omh-triage` — the worker skill - `omh-ralplan-driver` — the structural model this followed - The host project's `docs/triage/PROCESS.md` if one exists (defines the two-mode quick-file/grooming discipline that triage runs *within*)