$npx -y skills add rlaope/oh-my-hermes --skill design-orchestration[omh] Hermes design orchestration workflow: prepare a bounded design direction, existing-lane composition, and executor-neutral handoff.
| 1 | # Design Orchestration |
| 2 | |
| 3 | This is a Hermes-native `design-orchestration` workflow skill. |
| 4 | |
| 5 | ## Why This Exists |
| 6 | |
| 7 | `design-orchestration` lets Hermes users say that they want design handled without making them manually compose four specialist lanes or confusing preparation with completed visual work. |
| 8 | |
| 9 | ## Do Not Use When |
| 10 | |
| 11 | - The request is directly about premium multi-format quality or publishing; use `design-quality-gate`. |
| 12 | - The request is directly about frontend implementation, layout, responsive behavior, or a design system; use `frontend`. |
| 13 | - The request is directly about WCAG, keyboard, screen-reader, or semantic accessibility; use `accessibility-audit`. |
| 14 | - The request is directly about screenshots, visual regression, pixel diff, rendered layout, or a verdict; use `visual-qa`. |
| 15 | |
| 16 | ## Examples |
| 17 | |
| 18 | Good example: |
| 19 | |
| 20 | - Prompt: 디자인 맡겨줘. 기존 프로젝트 맥락을 먼저 보고, 방향과 구현·검증의 다음 단계를 잡아줘. |
| 21 | - Expected behavior: Prepare design_orchestration/v1 with opaque context references, deliberate direction, existing-lane composition, executor_selection_required, and not_observed visual evidence requirements. |
| 22 | - Why: The request delegates broad design ownership while leaving implementation and observed QA to the appropriate owners. |
| 23 | |
| 24 | Bad example: |
| 25 | |
| 26 | - Prompt: design-orchestration already rendered and visually passed the new page. |
| 27 | - Expected behavior: Keep rendering and visual PASS not_observed; route the required capture and verdict work to visual-qa. |
| 28 | - Why: A prepared orchestration contract cannot create implementation or rendered evidence. |
| 29 | |
| 30 | ## Completion Checklist |
| 31 | |
| 32 | - The bounded intent, opaque context references, direction vocabulary, and avoid patterns are explicit. |
| 33 | - The four downstream lanes retain their direct ownership and the executor is still selection-required. |
| 34 | - The visual evidence contract keeps visual_verdict not_observed until fresh captures are recorded by the visual-QA owner. |
| 35 | |
| 36 | ## Recovery Notes |
| 37 | |
| 38 | - If only a raw brief exists, let Hermes retain it in chat and create an opaque user-supplied reference instead of storing the brief. |
| 39 | - If the request narrows to implementation, accessibility, or rendered QA, route to the existing specialist rather than expanding this orchestration surface. |
| 40 | |
| 41 | ## OMH Context Rail |
| 42 | |
| 43 | - This skill is part of OMH's Hermes workflow layer, not a standalone executor. |
| 44 | - Product context: OMH is a Hermes-native workflow pack: choose skills, shape work, prepare artifacts, show status, and hand off with evidence boundaries. |
| 45 | - Current lane: **Materials and visual summaries** (`design-orchestration`, `design-quality-gate`, `frontend`, `accessibility-audit`, `visual-qa`, `content-operator`, `media-input-operator`, `materials-package`, `+3 more`) - web, accessibility, visual QA, files, and packages. |
| 46 | - 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. |
| 47 | - Cross-skill context: every OMH skill: match lane; generic tool can render or execute. |
| 48 | - 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. |
| 49 | - Coverage: Every generated workflow skill carries this rail. |
| 50 | - Normal users talk to Hermes; OMH CLI is infra. |
| 51 | - Boundary: Prepared OMH routing, cards, handoffs, or artifacts are not observed execution, image generation, delivery, review, CI, merge-readiness, or merge evidence. |
| 52 | |
| 53 | ## Use When |
| 54 | |
| 55 | Use when Hermes should take broad ownership of a design problem before a narrower quality, frontend, accessibility, or visual-QA lane is known. |
| 56 | |
| 57 | Strong routing signals: `design-orchestration`, `design orchestration`, `design ownership`, `handle this product design`, `take on the design`, `디자인 맡겨`, `디자인 맡겨줘`, `디자인 전체 맡겨`, `프로덕트 디자인 맡겨` |
| 58 | |
| 59 | ## Catalog Metadata |
| 60 | |
| 61 | Category: `materials` |
| 62 | Phase: `design-orchestration` |
| 63 | Hermes role: `operator` |
| 64 | Quality tier: `design-orchestration-gated` |
| 65 | |
| 66 | Quality bar: |
| 67 | |
| 68 | - Make the design job, context boundary, direction, downstream lane ownership, and visual evidence requirements readable before handoff. |
| 69 | - Reject generic default drift by naming hierarchy, palette, typography, layout, signature element, and avoid patterns deliberately. |
| 70 | - Require the selected executor and fresh visual evidence separately before any implementation or quality completion claim. |
| 71 | |
| 72 | Handoff policy: |
| 73 | |
| 74 | Keep design intent, opaque project context references, deliberate direction, and existing-lane composition |