omh-triage-driver

Name: omh-triage-driver
Author: witt3rd

117stars9forks

How to install omh-triage-driver?

witt3rd/oh-my-hermes/omh-triage-driver

$npx -y skills add witt3rd/oh-my-hermes --skill omh-triage-driver

Installs into the current project.

Summary

Drive omh-triage: when to invoke, how to run rounds.

Files · 1

View on GitHub

SKILL.md

1	# OMH Triage Driver — Driving a Triage Run
2
3	> 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.
4
5	## When You Are the Orchestrator
6
7	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.
8
9	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.
10
11	## Pre-flight Discipline
12
13	Before invoking `omh-triage`:
14
15	### Audit the backlog state
16
17	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.
18	2. Time since last grooming. If <2 weeks AND no major refactor landed, may not be worth a round.
19	3. Project board state (if any). Cards in "Won't ship" / staging columns should be drained by a triage round, not left to accumulate.
20	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.
21
22	### Audit the trigger
23
24	What's the actual reason for this run?
25
26	- "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.
27	- "Just shipped a major migration, several issues may be stale" → triage is a cleanup pass. Output is mostly closures.
28	- "Backlog feels heavy, want to prune" → Skeptic's pressure dominates; Maintainer is supporting. Frame the goal accordingly.
29	- "Periodic hygiene, no specific motivator" → low-priority; consider deferring until a triggering reason exists.
30
31	The trigger shapes how you weight the role outputs. A cleanup-pass run weights Maintainer; a pruning run weights Skeptic.
32
33	### Audit the host project's discipline
34
35	Does the host project have:
36	- A `docs/triage/PROCESS.md` documenting two-mode discipline (quick-file vs grooming)?
37	- A GitHub Project with target-version + cluster fields?
38	- A prior triage doc to delta against?
39
40	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.
41
42	## The dispatcher's job during the run
43
44	### During Phase 0 (context gathering)
45
46	You author the context package, not a subagent. The package shapes both subagents' work; getting it wrong wastes both passes.
47
48	The package must include:
49	- Repo HEAD ref (the anchor for Maintainer's vetting)
50	- List of recent migrations / refactors with brief description (so Maintainer doesn't re-derive)
51	- Issue count + label distribution + age distribution
52	- Prior triage doc summary (if any), specifically: what verdicts landed, what was deferred
53	- The trigger framing (cleanup vs pruning vs hygiene)
54
55	If the package is over ~1000 words, it's bloated. ~500 is the target.
56
57	### During Phase 1 (role passes)
58
59	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.
60
61	Watch for these failure modes (each becomes a numbered pitfall as it's lived):
62
63	- 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.
64	- 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.
65	- 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.
66
67	### During Phase 2 (distillation)
68
69	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.
70
71	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.
72
73	### During Phase 3 (execution)

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

omh-triage-driver

117stars9forks

View on GitHub

How to install omh-triage-driver?

witt3rd/oh-my-hermes/omh-triage-driver

$npx -y skills add witt3rd/oh-my-hermes --skill omh-triage-driver

Installs into the current project.

Summary

Drive omh-triage: when to invoke, how to run rounds.

Files · 1

View on GitHub

SKILL.md

1	# OMH Triage Driver — Driving a Triage Run
2
3	> 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.
4
5	## When You Are the Orchestrator
6
7	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.
8
9	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.
10
11	## Pre-flight Discipline
12
13	Before invoking `omh-triage`:
14
15	### Audit the backlog state
16
17	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.
18	2. Time since last grooming. If <2 weeks AND no major refactor landed, may not be worth a round.
19	3. Project board state (if any). Cards in "Won't ship" / staging columns should be drained by a triage round, not left to accumulate.
20	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.
21
22	### Audit the trigger
23
24	What's the actual reason for this run?
25
26	- "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.
27	- "Just shipped a major migration, several issues may be stale" → triage is a cleanup pass. Output is mostly closures.
28	- "Backlog feels heavy, want to prune" → Skeptic's pressure dominates; Maintainer is supporting. Frame the goal accordingly.
29	- "Periodic hygiene, no specific motivator" → low-priority; consider deferring until a triggering reason exists.
30
31	The trigger shapes how you weight the role outputs. A cleanup-pass run weights Maintainer; a pruning run weights Skeptic.
32
33	### Audit the host project's discipline
34
35	Does the host project have:
36	- A `docs/triage/PROCESS.md` documenting two-mode discipline (quick-file vs grooming)?
37	- A GitHub Project with target-version + cluster fields?
38	- A prior triage doc to delta against?
39
40	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.
41
42	## The dispatcher's job during the run
43
44	### During Phase 0 (context gathering)
45
46	You author the context package, not a subagent. The package shapes both subagents' work; getting it wrong wastes both passes.
47
48	The package must include:
49	- Repo HEAD ref (the anchor for Maintainer's vetting)
50	- List of recent migrations / refactors with brief description (so Maintainer doesn't re-derive)
51	- Issue count + label distribution + age distribution
52	- Prior triage doc summary (if any), specifically: what verdicts landed, what was deferred
53	- The trigger framing (cleanup vs pruning vs hygiene)
54
55	If the package is over ~1000 words, it's bloated. ~500 is the target.
56
57	### During Phase 1 (role passes)
58
59	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.
60
61	Watch for these failure modes (each becomes a numbered pitfall as it's lived):
62
63	- 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.
64	- 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.
65	- 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.
66
67	### During Phase 2 (distillation)
68
69	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.
70
71	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.
72
73	### During Phase 3 (execution)

People who liked this also viewed

6 picks

Type