/omh-apple-design

name: "omh-apple-design"
description: "[omh] Designing or reviewing an iOS, macOS, or Apple-style UI: prepare native Apple UI or Apple marketing product-visual direction, review, and improvement briefs with evidence-backed remediation handoffs. Use when the user says: apple-design, apple design, apple ui design, apple hig, human interface guidelines, ios design guidelines, macos app design, apple-inspired web."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, materials]
    category: materials
    phase: apple-design
    role: operator
    quality_tier: apple-design-gated

Apple Design

This is a Hermes-native `apple-design` workflow skill.

Why This Exists

`apple-design` turns Apple UI design, review, and improvement requests into a platform-aware brief that respects native and web differences while preserving OMH's existing implementation and evidence owners.

Do Not Use When

• The request is generic frontend design, accessibility, screenshot QA, image-card work, or material guidance without an Apple-specific phrase or explicit `apple-design` invocation; use the existing specialist lane.
• The message concerns Apple fruit, stock, support, a glass database, material science, or unrelated Swift/macOS discussion.
• The user needs a conformance, accessibility PASS, or visual PASS claim without supplied and observed evidence.

Examples

Good example:

• Prompt: Review this iPad checkout against Apple HIG and hand the concrete fixes to the frontend and accessibility owners.
• Expected behavior: Prepare apple_design_brief/v1 with applicable evidence, findings, platform-aware remediation, and the existing owner routes.
• Why: The request specifies an Apple platform and asks for a review plus downstream remediation without treating the brief as implementation or a verdict.

Bad example:

• Prompt: Call our generic WCAG screenshot check Apple-certified.
• Expected behavior: Keep the Apple-specific verdict unavailable and route generic accessibility or rendered evidence to the existing specialist.
• Why: A generic check without applicable Apple evidence cannot establish platform compliance or certification.

Completion Checklist

• Target, convention, state, and evidence are explicit.
• Each direction or finding names evidence, source applicability, owner, and missing verification; product visuals name original art direction.
• Implementation remains with the selected coding owner; accessibility and visual completion remain not_observed until their existing lanes record evidence.

Recovery Notes

• If the platform/version, convention, or target state is missing, ask for it before treating a guideline as applicable.
• If no supplied screen or code exists, prepare the brief and mark visual status not_observed rather than inferring a rendered result.

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 an iOS, iPadOS, macOS, Apple-inspired web surface, or explicit Apple-style product visual needs an Apple-aware direction, evidence-backed review, or improvement brief before implementation or visual verification.

Strong routing signals: `apple-design`, `apple design`, `apple ui design`, `apple hig`, `human interface guidelines`, `ios design guidelines`, `macos app design`, `apple-inspired web`, `liquid glass review`, `liquid glass design`, `apple 3d hero`, `apple-style 3d`, `apple product render`, `apple product visual`, `apple studio lighting`, `apple-style landing visual`, `apple product page`

Catalog Metadata

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

Quality bar:

• Start with mode, target, convention, and available evidence; choose directions before visuals when open.
• Load `references/platform-foundations.md`, `references/materials-and-accessibility.md`, `references/product-visual-production.md`, `references/web-production-libraries.md`, and `references/review-playbook.md` for their named boundaries.
• For product work, use reference -> actual production -> same-subject comparison -> revision. Motion needs frames, video, or browser evidence and a reduced-motion alternative; do not award an Apple score.
• Findings name evidence, impact, source/applicability, fix, owner, and missing check; route implementation to the selected owner and proof to accessibility-audit or visual-qa.

Handoff policy:

Hermes directs; selected owners implement and existing lanes observe.

Required inputs:

• mode: design, review, or improve
• visual target: Apple marketing/product visual, native Apple application, or Apple-inspired web UI
• target, surface/state, supplied evidence, and available execution constraints

Expected outputs:

• apple_design_brief/v1
• apple_visual_direction/v1
• apple_design_finding/v1 with severity, location/evidence, impact, source/applicability, fix, owner, and missing checks
• two to four design directions before visual work when direction is open
• composed remediation route to frontend, design-quality-gate, accessibility-audit, visual-qa, or award-bar-score

Artifact expectations:

• prepared Apple design brief with observations and hypotheses distinguished
• prepared product-visual handoff when no authorized execution path exists
• visual status not_observed when no supplied screen, capture, or rendered surface exists
• no Apple certification, accessibility PASS, visual PASS, or implementation claim from a prepared brief

Safety rules:

• Choose one target: marketing/product visual, native Apple applica