omh-ralph-driver

Name: omh-ralph-driver
Author: witt3rd

117stars9forks

How to install omh-ralph-driver?

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

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

Installs into the current project.

Summary

Drive an omh-ralph run: dispatch, evidence, commit hygiene.

Files · 1

View on GitHub

SKILL.md

1	# OMH Ralph Driver — orchestrator's playbook for verified execution
2
3	Load this skill alongside `omh-ralph` when you are the orchestrator
4	dispatching the loop. `omh-ralph` is loaded by the role-tagged
5	workers (executor / verifier / architect) — it covers the iron-law
6	discipline inside each task's `delegate_task` call. This skill covers
7	what you do as the dispatcher: plan-shape, iteration cadence,
8	parallel batching, evidence gathering, verifier dispatch, strike
9	handling, commit hygiene, and the final architect gate.
10
11	The two skills have different readers and different jobs. Don't merge
12	them — worker context is precious; the dispatcher's playbook should
13	not ride into every subagent.
14
15	This skill is the ralph-side counterpart to `omh-ralplan-driver`
16	(which is the dispatcher playbook for ralplan, the design loop). The
17	relationship is consistent: each method has a worker-side skill (used
18	inside delegate_task) and a driver-side skill (used by the orchestrator
19	between dispatches).
20
21	## When to use ralph vs just write the code
22
23	Use ralph when:
24
25	- You have a plan with 5+ independently-acceptable tasks (from
26	`omh-ralplan` or hand-authored).
27	- Quality-via-verification matters more than wall-clock — each task's
28	output must be evidence-graded before the next builds on it.
29	- You want clean checkpoints across many work units (no context bloat).
30	- Some tasks are independent and can run in parallel batches.
31
32	Don't use ralph when:
33
34	- The work is single-step or trivially obvious to write directly.
35	- No plan exists yet — run `omh-ralplan` (or for an obvious goal,
36	`omh-deep-interview` first) before invoking ralph.
37	- The user wants to skip verification (unusual; usually means the
38	work is small enough to do directly).
39
40	## The arc of a ralph run
41
42	```
43	iter 1: pick eligible tasks → dispatch executors (parallel where safe)
44	→ gather evidence → dispatch verifiers (parallel) → mark passes/fails
45	→ update state → release lock → exit
46
47	iter 2: re-invoke. Read state. Pick next batch. Same cycle.
48
49	...
50
51	iter N: all tasks pass → Step 7 final architect review → mark complete.
52	```
53
54	The orchestrator's job between iterations: pick the right batch, write
55	the right context for each executor, gather the right evidence, parse
56	the verifier verdicts, and decide whether to retry or move on.
57
58	## The five-step playbook
59
60	### 1. Read the plan; verify it is ralph-shaped
61
62	A ralph plan is a list of numbered tasks, each with:
63
64	- A clear title.
65	- A description tight enough that an executor with no prior context
66	can implement it.
67	- Acceptance criteria that are testable. Generic criteria like
68	"implementation is complete" are rejected by ralph's planning gate.
69	- Dependencies (which other tasks must be done first).
70	- Files-touched (for parallel-batch planning — see step 3).
71
72	If the plan came from `omh-ralplan`, it is design-shaped, not ralph-shaped. The stance's "MV slice" section is your starting point; you may need to translate it to ralph's task format. Author `.omh/plans/ralph-plan.md` (or `.omh/plans/ralplan-<slug>.md` if it derives from a specific ralplan instance) with proper task structure.
73
74	The plan does not need every task pre-authored to the same depth — it can grow. Ralph's planning gate parses what's there at first invocation; new tasks discovered during execution land via the `discovered: true` flag in state.
75
76	### 2. Pick the right batch for each iteration
77
78	Each ralph iteration does ONE unit of work. A "unit" can be:
79
80	- One task (when the next eligible task is alone, or has shared file
81	footprint with other eligibles)
82	- A batch of 2-4 tasks (when independents are eligible and have
83	disjoint touch sets)
84
85	Eligibility = `passes: false` AND all dependencies met.
86
87	Disjoint touch sets = the tasks do not modify the same files. Read
88	the plan's "Files to modify/create" lists. If two eligible tasks both
89	touch `bin/janus-new-being`, they are NOT parallel-safe — one owns
90	the modification. If one touches `migrations/lib.py` and another
91	touches `bin/_lineage.py`, they are parallel-safe.
92
93	Edge case — shared imports. Even if files are disjoint, if Task A
94	authors a helper that Task B imports, you may need Task A to land first.
95	Surface this in dependency declarations during plan-authoring; if you
96	miss it, the executor for B will surface the dependency mid-task.
97
98	Right batch size. 2-4 tasks. Five+ in one batch overloads
99	orchestrator parsing of executor reports + verifier dispatch in your
100	own context window.
101
102	### 3. Dispatch executors with rich context
103
104	Each executor gets a fresh subagent. Subagents have NO memory of
105	prior iterations, prior conversations, prior tasks. Encode everything
106	they need in the dispatch context.
107
108	The executor dispatch contex

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-ralph-driver

117stars9forks

View on GitHub

How to install omh-ralph-driver?

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

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

Installs into the current project.

Summary

Drive an omh-ralph run: dispatch, evidence, commit hygiene.

Files · 1

View on GitHub

SKILL.md

1	# OMH Ralph Driver — orchestrator's playbook for verified execution
2
3	Load this skill alongside `omh-ralph` when you are the orchestrator
4	dispatching the loop. `omh-ralph` is loaded by the role-tagged
5	workers (executor / verifier / architect) — it covers the iron-law
6	discipline inside each task's `delegate_task` call. This skill covers
7	what you do as the dispatcher: plan-shape, iteration cadence,
8	parallel batching, evidence gathering, verifier dispatch, strike
9	handling, commit hygiene, and the final architect gate.
10
11	The two skills have different readers and different jobs. Don't merge
12	them — worker context is precious; the dispatcher's playbook should
13	not ride into every subagent.
14
15	This skill is the ralph-side counterpart to `omh-ralplan-driver`
16	(which is the dispatcher playbook for ralplan, the design loop). The
17	relationship is consistent: each method has a worker-side skill (used
18	inside delegate_task) and a driver-side skill (used by the orchestrator
19	between dispatches).
20
21	## When to use ralph vs just write the code
22
23	Use ralph when:
24
25	- You have a plan with 5+ independently-acceptable tasks (from
26	`omh-ralplan` or hand-authored).
27	- Quality-via-verification matters more than wall-clock — each task's
28	output must be evidence-graded before the next builds on it.
29	- You want clean checkpoints across many work units (no context bloat).
30	- Some tasks are independent and can run in parallel batches.
31
32	Don't use ralph when:
33
34	- The work is single-step or trivially obvious to write directly.
35	- No plan exists yet — run `omh-ralplan` (or for an obvious goal,
36	`omh-deep-interview` first) before invoking ralph.
37	- The user wants to skip verification (unusual; usually means the
38	work is small enough to do directly).
39
40	## The arc of a ralph run
41
42	```
43	iter 1: pick eligible tasks → dispatch executors (parallel where safe)
44	→ gather evidence → dispatch verifiers (parallel) → mark passes/fails
45	→ update state → release lock → exit
46
47	iter 2: re-invoke. Read state. Pick next batch. Same cycle.
48
49	...
50
51	iter N: all tasks pass → Step 7 final architect review → mark complete.
52	```
53
54	The orchestrator's job between iterations: pick the right batch, write
55	the right context for each executor, gather the right evidence, parse
56	the verifier verdicts, and decide whether to retry or move on.
57
58	## The five-step playbook
59
60	### 1. Read the plan; verify it is ralph-shaped
61
62	A ralph plan is a list of numbered tasks, each with:
63
64	- A clear title.
65	- A description tight enough that an executor with no prior context
66	can implement it.
67	- Acceptance criteria that are testable. Generic criteria like
68	"implementation is complete" are rejected by ralph's planning gate.
69	- Dependencies (which other tasks must be done first).
70	- Files-touched (for parallel-batch planning — see step 3).
71
72	If the plan came from `omh-ralplan`, it is design-shaped, not ralph-shaped. The stance's "MV slice" section is your starting point; you may need to translate it to ralph's task format. Author `.omh/plans/ralph-plan.md` (or `.omh/plans/ralplan-<slug>.md` if it derives from a specific ralplan instance) with proper task structure.
73
74	The plan does not need every task pre-authored to the same depth — it can grow. Ralph's planning gate parses what's there at first invocation; new tasks discovered during execution land via the `discovered: true` flag in state.
75
76	### 2. Pick the right batch for each iteration
77
78	Each ralph iteration does ONE unit of work. A "unit" can be:
79
80	- One task (when the next eligible task is alone, or has shared file
81	footprint with other eligibles)
82	- A batch of 2-4 tasks (when independents are eligible and have
83	disjoint touch sets)
84
85	Eligibility = `passes: false` AND all dependencies met.
86
87	Disjoint touch sets = the tasks do not modify the same files. Read
88	the plan's "Files to modify/create" lists. If two eligible tasks both
89	touch `bin/janus-new-being`, they are NOT parallel-safe — one owns
90	the modification. If one touches `migrations/lib.py` and another
91	touches `bin/_lineage.py`, they are parallel-safe.
92
93	Edge case — shared imports. Even if files are disjoint, if Task A
94	authors a helper that Task B imports, you may need Task A to land first.
95	Surface this in dependency declarations during plan-authoring; if you
96	miss it, the executor for B will surface the dependency mid-task.
97
98	Right batch size. 2-4 tasks. Five+ in one batch overloads
99	orchestrator parsing of executor reports + verifier dispatch in your
100	own context window.
101
102	### 3. Dispatch executors with rich context
103
104	Each executor gets a fresh subagent. Subagents have NO memory of
105	prior iterations, prior conversations, prior tasks. Encode everything
106	they need in the dispatch context.
107
108	The executor dispatch contex

People who liked this also viewed

6 picks

Type