plan

Name: plan
Author: rlaope

61stars2forks

How to install plan?

rlaope/oh-my-hermes/plan

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

Installs into the current project.

Summary

[omh] Hermes Plan workflow: structured planning before execution.

Files · 1

View on GitHub

SKILL.md

1	# Plan
2
3	This is a Hermes-native `plan` workflow skill.
4
5	## Why This Exists
6
7	`plan` exists to keep `planning` work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.
8
9	## Do Not Use When
10
11	- The request is casual chat, a status-only acknowledgement, or another workflow has stronger routing evidence.
12	- The user needs implementation, review, CI, merge, or external publishing evidence that has not been delegated or observed.
13
14	## Examples
15
16	Good example:
17
18	- Prompt: plan: handle a planning request that needs explicit evidence boundaries and a clear stop condition.
19	- Expected behavior: Run `plan` only after naming the target, evidence boundary, and stop condition.
20	- Why: The request matches the catalog use case and keeps observed evidence separate from prepared guidance.
21
22	Bad example:
23
24	- Prompt: plan: treat casual chat or unaccepted work as if this workflow already produced verified results.
25	- Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing `plan`.
26	- Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.
27
28	## Completion Checklist
29
30	- The plan names goals, non-goals, assumptions, acceptance criteria, and verification shape.
31	- Draft recommendations, accepted decisions, and executor handoffs are separate states.
32	- Rejected options or unresolved tradeoffs are recorded before handoff.
33
34	## Recovery Notes
35
36	- If acceptance criteria or verification are missing, route back to clarification before handoff.
37	- If assumptions materially affect the plan, keep them visible and avoid treating the plan as accepted.
38
39	## OMH Context Rail
40
41	- This skill is part of OMH's Hermes workflow layer, not a standalone executor.
42	- Product context: OMH is a Hermes-native workflow pack: choose skills, shape work, prepare artifacts, show status, and hand off with evidence boundaries.
43	- 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.
44	- 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.
45	- Cross-skill context: every OMH skill: match lane; generic tool can render or execute.
46	- 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.
47	- Coverage: Every generated workflow skill carries this rail.
48	- Normal users talk to Hermes; OMH CLI is infra.
49	- Boundary: Prepared OMH routing, cards, handoffs, or artifacts are not observed execution, image generation, delivery, review, CI, merge-readiness, or merge evidence.
50
51	## Use When
52
53	Use for structured planning when implementation is not ready to start safely, including feature work that needs a safe plan before handoff.
54
55	Strong routing signals: `plan`, `$plan`, `implementation plan`, `strategy`, `task breakdown`, `safe feature`, `safely add a feature`, `add a feature`, `feature request`, `new feature`, `product triage`, `bug triage`, `issue triage`, `reproduction plan`, `workflow hub`, `coding handoff`, `답할 차례`, `준비할 차례`, `project template`, `재현 계획`, `요구사항 정리`, `작업 허브`, `작업 허브가 필요`, `github pr workflow`, `상태와 다음 행동`, `프로젝트별 운영`
56
57	## Catalog Metadata
58
59	Category: `planning`
60	Phase: `plan`
61	Hermes role: `planner`
62	Quality tier: `acceptance-gated`
63
64	Quality bar:
65
66	- Make goals, non-goals, risks, acceptance criteria, and verification shape explicit.
67	- Keep draft plans unapproved until a user or wrapper accepts them.
68	- Only prepare coding handoff guidance after the plan is accepted.
69
70	Handoff policy:
71
72	Keep planning in Hermes; if the accepted plan requires code edits, prepare a selected executor/runtime handoff after acceptance.
73
74	Required inputs:
75
76	- requirements
77	- constraints
78	- known facts
79	- non-goals
80
81	Expected outputs:
82
83	- plan
84	- acceptance criteria
85	- verification strategy
86
87	Artifact expectations:
88
89	- plan artifact when durable execution will follow
90
91	Safety rules:
92
93	- Do not imply hidden Hermes runtime behavior.
94	- Use the smallest verification that can prove the claim.
95
96	## Harness Discipline
97
98	- Start from the representative harness registry in `oh-my-hermes` when the workflow needs coding, research, planning, goal execution, architecture, critique, QA, or documentation lanes.
99	- Prefer richer evidence and clearer stop conditions over adding more workflow names.
100	- Use specialist lanes o

People who liked this also viewed

6 picks

Type

plan

61stars2forks

View on GitHub

How to install plan?

rlaope/oh-my-hermes/plan

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

Installs into the current project.

Summary

[omh] Hermes Plan workflow: structured planning before execution.

Files · 1

View on GitHub

SKILL.md

1	# Plan
2
3	This is a Hermes-native `plan` workflow skill.
4
5	## Why This Exists
6
7	`plan` exists to keep `planning` work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.
8
9	## Do Not Use When
10
11	- The request is casual chat, a status-only acknowledgement, or another workflow has stronger routing evidence.
12	- The user needs implementation, review, CI, merge, or external publishing evidence that has not been delegated or observed.
13
14	## Examples
15
16	Good example:
17
18	- Prompt: plan: handle a planning request that needs explicit evidence boundaries and a clear stop condition.
19	- Expected behavior: Run `plan` only after naming the target, evidence boundary, and stop condition.
20	- Why: The request matches the catalog use case and keeps observed evidence separate from prepared guidance.
21
22	Bad example:
23
24	- Prompt: plan: treat casual chat or unaccepted work as if this workflow already produced verified results.
25	- Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing `plan`.
26	- Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.
27
28	## Completion Checklist
29
30	- The plan names goals, non-goals, assumptions, acceptance criteria, and verification shape.
31	- Draft recommendations, accepted decisions, and executor handoffs are separate states.
32	- Rejected options or unresolved tradeoffs are recorded before handoff.
33
34	## Recovery Notes
35
36	- If acceptance criteria or verification are missing, route back to clarification before handoff.
37	- If assumptions materially affect the plan, keep them visible and avoid treating the plan as accepted.
38
39	## OMH Context Rail
40
41	- This skill is part of OMH's Hermes workflow layer, not a standalone executor.
42	- Product context: OMH is a Hermes-native workflow pack: choose skills, shape work, prepare artifacts, show status, and hand off with evidence boundaries.
43	- 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.
44	- 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.
45	- Cross-skill context: every OMH skill: match lane; generic tool can render or execute.
46	- 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.
47	- Coverage: Every generated workflow skill carries this rail.
48	- Normal users talk to Hermes; OMH CLI is infra.
49	- Boundary: Prepared OMH routing, cards, handoffs, or artifacts are not observed execution, image generation, delivery, review, CI, merge-readiness, or merge evidence.
50
51	## Use When
52
53	Use for structured planning when implementation is not ready to start safely, including feature work that needs a safe plan before handoff.
54
55	Strong routing signals: `plan`, `$plan`, `implementation plan`, `strategy`, `task breakdown`, `safe feature`, `safely add a feature`, `add a feature`, `feature request`, `new feature`, `product triage`, `bug triage`, `issue triage`, `reproduction plan`, `workflow hub`, `coding handoff`, `답할 차례`, `준비할 차례`, `project template`, `재현 계획`, `요구사항 정리`, `작업 허브`, `작업 허브가 필요`, `github pr workflow`, `상태와 다음 행동`, `프로젝트별 운영`
56
57	## Catalog Metadata
58
59	Category: `planning`
60	Phase: `plan`
61	Hermes role: `planner`
62	Quality tier: `acceptance-gated`
63
64	Quality bar:
65
66	- Make goals, non-goals, risks, acceptance criteria, and verification shape explicit.
67	- Keep draft plans unapproved until a user or wrapper accepts them.
68	- Only prepare coding handoff guidance after the plan is accepted.
69
70	Handoff policy:
71
72	Keep planning in Hermes; if the accepted plan requires code edits, prepare a selected executor/runtime handoff after acceptance.
73
74	Required inputs:
75
76	- requirements
77	- constraints
78	- known facts
79	- non-goals
80
81	Expected outputs:
82
83	- plan
84	- acceptance criteria
85	- verification strategy
86
87	Artifact expectations:
88
89	- plan artifact when durable execution will follow
90
91	Safety rules:
92
93	- Do not imply hidden Hermes runtime behavior.
94	- Use the smallest verification that can prove the claim.
95
96	## Harness Discipline
97
98	- Start from the representative harness registry in `oh-my-hermes` when the workflow needs coding, research, planning, goal execution, architecture, critique, QA, or documentation lanes.
99	- Prefer richer evidence and clearer stop conditions over adding more workflow names.
100	- Use specialist lanes o

People who liked this also viewed

6 picks

Type