ralplan

Name: ralplan
Author: rlaope

61stars2forks

How to install ralplan?

rlaope/oh-my-hermes/ralplan

$npx -y skills add rlaope/oh-my-hermes --skill ralplan

Installs into the current project.

Summary

[omh] Hermes Ralplan workflow: consensus planning with review gates.

Files · 1

View on GitHub

SKILL.md

1	# Ralplan
2
3	This is a Hermes-native `ralplan` workflow skill.
4
5	## Why This Exists
6
7	`ralplan` exists to make planning reviewable before execution: Hermes should gather codebase/source facts, compare options, expose risks, define acceptance criteria, and prepare a handoff without pretending implementation already happened.
8
9	## Do Not Use When
10
11	- The request is still too ambiguous to name requirements, non-goals, or acceptance criteria; use `deep-interview` first.
12	- The user asks for one full research-plan-implementation-review-PR cycle; use `ultraprocess` and keep ralplan as the planning stage.
13	- The user wants a pure source lookup, citation check, or paper explanation with no implementation plan.
14
15	## Examples
16
17	Good example:
18
19	- Prompt: $ralplan turn this risky refactor into a reviewable plan with acceptance criteria and verification commands.
20	- Expected behavior: Produce repo/source facts, alternatives, risk review, acceptance criteria, exact verification commands, and handoff readiness without editing code.
21	- Why: The request is clear enough to plan but risky enough to require consensus-style review before execution.
22
23	Bad example:
24
25	- Prompt: $ralplan implement the refactor now and open the PR.
26	- Expected behavior: Stop at the reviewed plan or route the full delivery cycle to `ultraprocess` after plan acceptance.
27	- Why: Ralplan is a planning gate, not implementation, review, CI, or PR evidence.
28
29	## Completion Checklist
30
31	- Observed repo facts and source/web evidence gaps are named.
32	- At least two options or one chosen option plus rejected alternatives are recorded.
33	- Risks, acceptance criteria, and verification commands are testable or explicitly blocked.
34	- The implementation handoff is prepared only after plan acceptance and remains prepared_not_observed.
35
36	## Recovery Notes
37
38	- If requirements are still fuzzy, route back to deep-interview before planning.
39	- If current-source evidence is missing, route a web-research step before accepting the plan.
40	- If the user asks for implementation, hand off through ultraprocess, ultragoal, or the selected executor path after the plan is accepted.
41
42	## OMH Context Rail
43
44	- This skill is part of OMH's Hermes workflow layer, not a standalone executor.
45	- Product context: OMH is a Hermes-native workflow pack: choose skills, shape work, prepare artifacts, show status, and hand off with evidence boundaries.
46	- Current lane: Intent -> plan (`oh-my-hermes`, `deep-interview`, `plan`, `ralplan`, `codebase-onboarding`, `codegraph-refresh`, `ultragoal`, `ultraprocess`, `+3 more`) - clarify, plan, ship, or loop goals.
47	- If the user intent belongs to another OMH lane, hand back to `oh-my-hermes` or name the adjacent workflow instead of force-fitting this skill.
48	- Cross-skill context: every OMH skill: match lane; generic tool can render or execute.
49	- Generic-tool checkpoint: image->img-summary; frontend->frontend/a11y/visual-qa; paper->paper-learning; content->content-operator; media->media-input-operator; file->materials-package; search->web-research; live->live-info-operator; audit->workspace/production/security; failures->build-failure; verify->verification-gate; code->codegraph/onboarding/ultraprocess.
50	- Coverage: Every generated workflow skill carries this rail.
51	- Normal users talk to Hermes; OMH CLI is infra.
52	- Boundary: Prepared OMH routing, cards, handoffs, or artifacts are not observed execution, image generation, delivery, review, CI, merge-readiness, or merge evidence.
53
54	## Use When
55
56	Use when requirements are clear enough for planning but architecture, evidence, alternatives, risks, or tests need a reviewed plan before execution.
57
58	Strong routing signals: `ralplan`, `$ralplan`, `consensus plan`, `reviewed plan`, `issue to PR`, `acceptance criteria`, `verification command`, `reviewable PR`, `risky planning`, `dangerous`, `dangerous planning`, `unsafe`, `refactor safety`, `PR로 만들`, `PR로 만들 수 있게`, `위험한 리팩터링`, `리팩터링 위험`, `리스크 있는 리팩터링`, `검증 command`, `리뷰 가능한 단위`, `코드베이스 조사`, `웹리서치 계획`, `대안 비교`, `리스크 검토`
59
60	## Catalog Metadata
61
62	Category: `planning`
63	Phase: `reviewed-plan`
64	Hermes role: `planner`
65	Quality tier: `reviewed-plan-gated`
66
67	Quality bar:
68
69	- Start from observed repo facts and source/web evidence when freshness or external behavior matters.
70	- Include planner view, critic/risk review, alternative paths, rejected options, and a testability check before handoff.
71	- Produce testable acceptance criteria and exact verification commands or explain why they are not yet knowable.
72	- Record unresolved tradeoffs and evidence gaps instead of flattening uncertainty.
73	- End with a selected executor/runtime handoff shape only after the plan is accepted.
74	- Do not implement directly from consensus planning.
75
76	Handoff policy:
77
78	Keep c

People who liked this also viewed

6 picks

Type

ralplan

61stars2forks

View on GitHub

How to install ralplan?

rlaope/oh-my-hermes/ralplan

$npx -y skills add rlaope/oh-my-hermes --skill ralplan

Installs into the current project.

Summary

[omh] Hermes Ralplan workflow: consensus planning with review gates.

Files · 1

View on GitHub

SKILL.md

1	# Ralplan
2
3	This is a Hermes-native `ralplan` workflow skill.
4
5	## Why This Exists
6
7	`ralplan` exists to make planning reviewable before execution: Hermes should gather codebase/source facts, compare options, expose risks, define acceptance criteria, and prepare a handoff without pretending implementation already happened.
8
9	## Do Not Use When
10
11	- The request is still too ambiguous to name requirements, non-goals, or acceptance criteria; use `deep-interview` first.
12	- The user asks for one full research-plan-implementation-review-PR cycle; use `ultraprocess` and keep ralplan as the planning stage.
13	- The user wants a pure source lookup, citation check, or paper explanation with no implementation plan.
14
15	## Examples
16
17	Good example:
18
19	- Prompt: $ralplan turn this risky refactor into a reviewable plan with acceptance criteria and verification commands.
20	- Expected behavior: Produce repo/source facts, alternatives, risk review, acceptance criteria, exact verification commands, and handoff readiness without editing code.
21	- Why: The request is clear enough to plan but risky enough to require consensus-style review before execution.
22
23	Bad example:
24
25	- Prompt: $ralplan implement the refactor now and open the PR.
26	- Expected behavior: Stop at the reviewed plan or route the full delivery cycle to `ultraprocess` after plan acceptance.
27	- Why: Ralplan is a planning gate, not implementation, review, CI, or PR evidence.
28
29	## Completion Checklist
30
31	- Observed repo facts and source/web evidence gaps are named.
32	- At least two options or one chosen option plus rejected alternatives are recorded.
33	- Risks, acceptance criteria, and verification commands are testable or explicitly blocked.
34	- The implementation handoff is prepared only after plan acceptance and remains prepared_not_observed.
35
36	## Recovery Notes
37
38	- If requirements are still fuzzy, route back to deep-interview before planning.
39	- If current-source evidence is missing, route a web-research step before accepting the plan.
40	- If the user asks for implementation, hand off through ultraprocess, ultragoal, or the selected executor path after the plan is accepted.
41
42	## OMH Context Rail
43
44	- This skill is part of OMH's Hermes workflow layer, not a standalone executor.
45	- Product context: OMH is a Hermes-native workflow pack: choose skills, shape work, prepare artifacts, show status, and hand off with evidence boundaries.
46	- Current lane: Intent -> plan (`oh-my-hermes`, `deep-interview`, `plan`, `ralplan`, `codebase-onboarding`, `codegraph-refresh`, `ultragoal`, `ultraprocess`, `+3 more`) - clarify, plan, ship, or loop goals.
47	- If the user intent belongs to another OMH lane, hand back to `oh-my-hermes` or name the adjacent workflow instead of force-fitting this skill.
48	- Cross-skill context: every OMH skill: match lane; generic tool can render or execute.
49	- Generic-tool checkpoint: image->img-summary; frontend->frontend/a11y/visual-qa; paper->paper-learning; content->content-operator; media->media-input-operator; file->materials-package; search->web-research; live->live-info-operator; audit->workspace/production/security; failures->build-failure; verify->verification-gate; code->codegraph/onboarding/ultraprocess.
50	- Coverage: Every generated workflow skill carries this rail.
51	- Normal users talk to Hermes; OMH CLI is infra.
52	- Boundary: Prepared OMH routing, cards, handoffs, or artifacts are not observed execution, image generation, delivery, review, CI, merge-readiness, or merge evidence.
53
54	## Use When
55
56	Use when requirements are clear enough for planning but architecture, evidence, alternatives, risks, or tests need a reviewed plan before execution.
57
58	Strong routing signals: `ralplan`, `$ralplan`, `consensus plan`, `reviewed plan`, `issue to PR`, `acceptance criteria`, `verification command`, `reviewable PR`, `risky planning`, `dangerous`, `dangerous planning`, `unsafe`, `refactor safety`, `PR로 만들`, `PR로 만들 수 있게`, `위험한 리팩터링`, `리팩터링 위험`, `리스크 있는 리팩터링`, `검증 command`, `리뷰 가능한 단위`, `코드베이스 조사`, `웹리서치 계획`, `대안 비교`, `리스크 검토`
59
60	## Catalog Metadata
61
62	Category: `planning`
63	Phase: `reviewed-plan`
64	Hermes role: `planner`
65	Quality tier: `reviewed-plan-gated`
66
67	Quality bar:
68
69	- Start from observed repo facts and source/web evidence when freshness or external behavior matters.
70	- Include planner view, critic/risk review, alternative paths, rejected options, and a testability check before handoff.
71	- Produce testable acceptance criteria and exact verification commands or explain why they are not yet knowable.
72	- Record unresolved tradeoffs and evidence gaps instead of flattening uncertainty.
73	- End with a selected executor/runtime handoff shape only after the plan is accepted.
74	- Do not implement directly from consensus planning.
75
76	Handoff policy:
77
78	Keep c

People who liked this also viewed

6 picks

Type