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, apple-design, design-quality-gate, award-bar-score, frontend, accessibility-audit, visual-qa, content-operator, +6 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 — the direction vocabulary and anti-slop patterns live in the frontend skill's omh-frontend/references/taste-foundations.md; prepared directions inherit its named bar (technically clean but flat fails).
• 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.

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. Reply in the user's own words and the host's own voice: its SOUL.md persona owns reply language, tone, speech level, and sentence endings, progress updates included (where it sets no language, use the one the user wrote in), and OMH shapes structure and content only; OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done.

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.