omh-ralph-task

Name: omh-ralph-task
Author: witt3rd

117stars9forks

How to install omh-ralph-task?

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

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

Installs into the current project.

Summary

Execute one omh-ralph task: file-scope, commit, report.

Files · 1

View on GitHub

SKILL.md

1	# omh-ralph-task — executor discipline
2
3	You are seeing this skill because an omh-ralph dispatcher (orchestrator) handed you a task envelope. You are the executor, not the dispatcher. Your job is narrow:
4
5	1. Do exactly the task the envelope specifies, no more.
6	2. Stay inside the file scope the envelope declares.
7	3. Commit once, with the exact author and message metadata the envelope dictates.
8	4. Report back in the shape the orchestrator expects.
9
10	The dispatcher trusts your report. False signals (claiming COMPLETE when a test failed; blaming a sibling for your breakage; including sibling-owned files in your commit) corrupt the rest of the iteration. Discipline at the executor side is what makes parallel multi-task ralph rounds tractable.
11
12	## The task envelope contract
13
14	The orchestrator gives you, at minimum:
15	- Project root + branch (where to work, which branch to commit on)
16	- Commit author (e.g. `<being-name> <being-email> (orchestrator-specified)`)
17	- Files this task owns (the only files you may stage)
18	- DO NOT modify (sibling tasks own these — read-only for you)
19	- Acceptance criteria (the bar the orchestrator will verify against)
20	- TDD instruction (whether to write failing tests first)
21	- Commit metadata (exact `git add` invocation and exact commit message body)
22	- Output expected (the report shape)
23
24	If any of these are missing or contradictory, ask the orchestrator before writing — don't infer your way through a missing constraint.
25
26	## Lifecycle
27
28	### 1. Orient
29
30	- Read the envelope twice. Note files-you-own AND files-others-own.
31	- Verify branch + HEAD match what the envelope says: `git status && git log -1 --oneline`.
32	- Read the required-reading list. The envelope tells you what design context matters.
33	- Read the files-others-own only if you need them for context — never modify.
34
35	### 2. TDD when instructed
36
37	The envelope often says: "Author failing tests FIRST. Run. Watch them fail with real assertion errors."
38
39	This is not optional when stated. Sequence:
40	1. Write the test file (or extend an existing one).
41	2. Run it: `uv run pytest <path> -q`.
42	3. Confirm RED with real assertion errors (not collection errors, not import failures).
43	4. THEN modify the implementation.
44	5. Run the new tests. Confirm GREEN.
45	6. Run the full suite. Confirm no regressions.
46
47	Going green-first (writing the implementation before the test) defeats the orchestrator's audit signal — they wanted to see real test-driven evidence in the commit, not after-the-fact tests rationalized to pass.
48
49	### 3. Stay in your file scope
50
51	When implementing, you may need to read sibling-owned files for context. You may not modify them. If you find yourself needing to modify a sibling-owned file to make your task work, that's a coordination signal — `BLOCKED` back to the orchestrator with the specific cross-task dependency, don't silently bleed.
52
53	### 4. Run the full suite
54
55	Even when you only added narrow tests, run the full suite per the envelope's instruction. The orchestrator wants regression confirmation.
56
57	### 5. Sibling-task isolation: the stash-verify move
58
59	This is the most-non-trivial executor discipline.
60
61	Scenario: you finish your work, run the full suite, and one or more failures appear in files outside your owned set. Three reflexes are all wrong:
62
63	- Wrong reflex A — panic and fail loud as if you broke them.
64	- Wrong reflex B — assume they're sibling-owned without verification and report COMPLETE.
65	- Wrong reflex C — fix them yourself ("just one line, easy") — bleeds into sibling lane.
66
67	Right move: verify ownership empirically before reporting.
68
69	```bash
70	# 1. Stash your work (keeps the failing-suite state preserved as "your tree minus your work")
71	git stash
72
73	# 2. Run the same failing test against pristine HEAD
74	uv run pytest <failing-test-path> -q
75
76	# 3a. If pristine PASSES → the failure is yours. Pop, fix, retry.
77	# 3b. If pristine FAILS → the failure is pre-existing or sibling-induced. Pop and continue.
78	git stash pop
79	```
80
81	If pristine HEAD passes the test but your tree fails, the failure is yours — don't pop with a half-fix; investigate. If pristine HEAD also fails the test, you've proven the failure is sibling-task or pre-existing, and you can report COMPLETE with an honest "1 sibling-task failure I confirmed isn't mine" note for the orchestrator.
82
83	The orchestrator is running multiple tasks in parallel. Without this verification you cannot honestly distinguish "I broke it" from "they broke it" from "it was already broken." Every executor that skips this move corrupts the iteration's signal.
84
85	See `references/sibling-isolation-pattern.md` for the canonical narrated example.
86
87	### 6. Commit with envelope-specified auth

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-task

117stars9forks

View on GitHub

How to install omh-ralph-task?

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

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

Installs into the current project.

Summary

Execute one omh-ralph task: file-scope, commit, report.

Files · 1

View on GitHub

SKILL.md

1	# omh-ralph-task — executor discipline
2
3	You are seeing this skill because an omh-ralph dispatcher (orchestrator) handed you a task envelope. You are the executor, not the dispatcher. Your job is narrow:
4
5	1. Do exactly the task the envelope specifies, no more.
6	2. Stay inside the file scope the envelope declares.
7	3. Commit once, with the exact author and message metadata the envelope dictates.
8	4. Report back in the shape the orchestrator expects.
9
10	The dispatcher trusts your report. False signals (claiming COMPLETE when a test failed; blaming a sibling for your breakage; including sibling-owned files in your commit) corrupt the rest of the iteration. Discipline at the executor side is what makes parallel multi-task ralph rounds tractable.
11
12	## The task envelope contract
13
14	The orchestrator gives you, at minimum:
15	- Project root + branch (where to work, which branch to commit on)
16	- Commit author (e.g. `<being-name> <being-email> (orchestrator-specified)`)
17	- Files this task owns (the only files you may stage)
18	- DO NOT modify (sibling tasks own these — read-only for you)
19	- Acceptance criteria (the bar the orchestrator will verify against)
20	- TDD instruction (whether to write failing tests first)
21	- Commit metadata (exact `git add` invocation and exact commit message body)
22	- Output expected (the report shape)
23
24	If any of these are missing or contradictory, ask the orchestrator before writing — don't infer your way through a missing constraint.
25
26	## Lifecycle
27
28	### 1. Orient
29
30	- Read the envelope twice. Note files-you-own AND files-others-own.
31	- Verify branch + HEAD match what the envelope says: `git status && git log -1 --oneline`.
32	- Read the required-reading list. The envelope tells you what design context matters.
33	- Read the files-others-own only if you need them for context — never modify.
34
35	### 2. TDD when instructed
36
37	The envelope often says: "Author failing tests FIRST. Run. Watch them fail with real assertion errors."
38
39	This is not optional when stated. Sequence:
40	1. Write the test file (or extend an existing one).
41	2. Run it: `uv run pytest <path> -q`.
42	3. Confirm RED with real assertion errors (not collection errors, not import failures).
43	4. THEN modify the implementation.
44	5. Run the new tests. Confirm GREEN.
45	6. Run the full suite. Confirm no regressions.
46
47	Going green-first (writing the implementation before the test) defeats the orchestrator's audit signal — they wanted to see real test-driven evidence in the commit, not after-the-fact tests rationalized to pass.
48
49	### 3. Stay in your file scope
50
51	When implementing, you may need to read sibling-owned files for context. You may not modify them. If you find yourself needing to modify a sibling-owned file to make your task work, that's a coordination signal — `BLOCKED` back to the orchestrator with the specific cross-task dependency, don't silently bleed.
52
53	### 4. Run the full suite
54
55	Even when you only added narrow tests, run the full suite per the envelope's instruction. The orchestrator wants regression confirmation.
56
57	### 5. Sibling-task isolation: the stash-verify move
58
59	This is the most-non-trivial executor discipline.
60
61	Scenario: you finish your work, run the full suite, and one or more failures appear in files outside your owned set. Three reflexes are all wrong:
62
63	- Wrong reflex A — panic and fail loud as if you broke them.
64	- Wrong reflex B — assume they're sibling-owned without verification and report COMPLETE.
65	- Wrong reflex C — fix them yourself ("just one line, easy") — bleeds into sibling lane.
66
67	Right move: verify ownership empirically before reporting.
68
69	```bash
70	# 1. Stash your work (keeps the failing-suite state preserved as "your tree minus your work")
71	git stash
72
73	# 2. Run the same failing test against pristine HEAD
74	uv run pytest <failing-test-path> -q
75
76	# 3a. If pristine PASSES → the failure is yours. Pop, fix, retry.
77	# 3b. If pristine FAILS → the failure is pre-existing or sibling-induced. Pop and continue.
78	git stash pop
79	```
80
81	If pristine HEAD passes the test but your tree fails, the failure is yours — don't pop with a half-fix; investigate. If pristine HEAD also fails the test, you've proven the failure is sibling-task or pre-existing, and you can report COMPLETE with an honest "1 sibling-task failure I confirmed isn't mine" note for the orchestrator.
82
83	The orchestrator is running multiple tasks in parallel. Without this verification you cannot honestly distinguish "I broke it" from "they broke it" from "it was already broken." Every executor that skips this move corrupts the iteration's signal.
84
85	See `references/sibling-isolation-pattern.md` for the canonical narrated example.
86
87	### 6. Commit with envelope-specified auth

People who liked this also viewed

6 picks

Type