Design Orchestration

This is a Hermes-native design-orchestration workflow skill.

Why This Exists

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.

Do Not Use When

• The request is directly about premium multi-format quality or publishing; use design-quality-gate.
• The request is directly about frontend implementation, layout, responsive behavior, or a design system; use frontend.
• The request is directly about WCAG, keyboard, screen-reader, or semantic accessibility; use accessibility-audit.
• The request is directly about screenshots, visual regression, pixel diff, rendered layout, or a verdict; use visual-qa.

Examples

Good example:

• Prompt: 디자인 맡겨줘. 기존 프로젝트 맥락을 먼저 보고, 방향과 구현·검증의 다음 단계를 잡아줘.
• Expected behavior: Prepare design_orchestration/v1 with opaque context references, deliberate direction, existing-lane composition, executor_selection_required, and not_observed visual evidence requirements.
• Why: The request delegates broad design ownership while leaving implementation and observed QA to the appropriate owners.

Bad example:

• Prompt: design-orchestration already rendered and visually passed the new page.
• Expected behavior: Keep rendering and visual PASS not_observed; route the required capture and verdict work to visual-qa.
• Why: A prepared orchestration contract cannot create implementation or rendered evidence.

Completion Checklist

• The bounded intent, opaque context references, direction vocabulary, and avoid patterns are explicit.
• The four downstream lanes retain their direct ownership and the executor is still selection-required.
• The visual evidence contract keeps visual_verdict not_observed until fresh captures are recorded by the visual-QA owner.

Recovery Notes

• If only a raw brief exists, let Hermes retain it in chat and create an opaque user-supplied reference instead of storing the brief.
• If the request narrows to implementation, accessibility, or rendered QA, route to the existing specialist rather than expanding this orchestration surface.

Workflow Lane

• Current lane: Materials and visual summaries (design-orchestration, design-quality-gate, frontend, accessibility-audit, visual-qa, content-operator, media-input-operator, materials-package, +4 more) - web, accessibility, visual QA, files, and packages.
• If intent belongs to another lane, hand back to oh-my-hermes or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: omh-routing/references/skill-common-rail.md.

Use When

Use when Hermes should take broad ownership of a design problem before a narrower quality, frontend, accessibility, or visual-QA lane is known.

Strong routing signals: design-orchestration, design orchestration, design ownership, handle this product design, take on the design, 디자인 맡겨, 디자인 맡겨줘, 디자인 전체 맡겨, 프로덕트 디자인 맡겨

Catalog Metadata

Category: materials Phase: design-orchestration Hermes role: operator Quality tier: design-orchestration-gated Reasoning demand: standard

Quality bar:

• Make the design job, context boundary, direction, downstream lane ownership, and visual evidence requirements readable before handoff.
• Reject generic default drift by naming hierarchy, palette, typography, layout, signature element, and avoid patterns deliberately.
• Require the selected executor and fresh visual evidence separately before any implementation or quality completion claim.

Handoff policy:

Keep design intent, opaque project context references, deliberate direction, and existing-lane composition in Hermes; prepare an executor-neutral handoff only. The selected executor owns implementation, while existing visual-QA and web-QA paths own observed rendered evidence.

Required inputs:

• bounded target surface, audience, and primary task
• at least one opaque project, user, or Hermes context reference
• direction vocabulary and avoid-pattern selection
• executor selection and observed visual evidence remain pending

Expected outputs:

• design_orchestration/v1
• design_direction_set/v1 when the direction is still open
• design intent and opaque context-reference boundary
• prepared direction vocabulary
• downstream composition: design-quality-gate, frontend, accessibility-audit, visual-qa
• executor-neutral handoff with executor_selection_required
• visual evidence requirements with visual_verdict not_observed

Artifact expectations:

• design_orchestration/v1 with prepared_not_observed status
• design_direction_set/v1 offers two to four directions with chosen_option empty until the user picks
• a static self-contained preview file when one is written; no server, port, or browser launch
• no raw project source, prompt, asset, path, or URL retention
• no executor target, dispatch, implementation, render, QA PASS, review, CI, deployment, or merge claim

Safety rules:

• Preserve the existing direct owners: design-quality-gate for premium multi-format quality, frontend for web implementation/design-system work, accessibility-audit for semantic access review, and visual-qa for fresh rendered verdicts.
• Do not use a prepared direction to claim code, screenshots, browser QA, accessibility PASS, review, CI, deployment, or merge.
• Keep free-form briefs in Hermes conversation context; persist only closed vocabulary and opaque reference metadata in the deterministic artifact.
• Do not call Claude Design, Figma, Open Design, an image provider, browser, network service, daemon, or executor from OMH core.

Runtime Evidence

Preferred harness for this skill: design-orchestration.

sh
omh runtime record --skill design-orchestration --harness design-orchestration --status started

Record observed delegation results; otherwise return not_available or not_observed. Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.

• Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.

Preserve workflow intent and stop conditions; verify before claiming completion.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.