본문으로 건너뛰기
cccskills
무료GitHub에 공개

omh-apple-design

Prepare design directions and improvement briefs for Apple platform apps, Apple-inspired websites, or product visuals. Review supplied evidence, explain which guidelines apply, and hand concrete fixes to the appropriate implementation and verification workflows.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

[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.

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • Reviewing an iPad checkout against Apple HIG
  • Planning an Apple-inspired website design
  • Defining product visual directions
  • Preparing evidence-based fixes for implementation

포함된 파일(6)

  • SKILL.md9.0 KB
  • references/materials-and-accessibility.md2.4 KB
  • references/platform-foundations.md2.8 KB
  • references/product-visual-production.md5.0 KB
  • references/review-playbook.md2.3 KB
  • references/web-production-libraries.md4.4 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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 omh-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 (show-reel, design-orchestration, apple-design, design-quality-gate, award-bar-score, frontend, accessibility-audit, visual-qa, +7 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: skill_view(name='omh-routing', file_path='references/skill-common-rail.md').

When to Use

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 application, or Apple-inspired web UI; do not substitute marketing or web effects for native controls/Liquid Glass.
  • For native targets use current HIG/system controls and platform foundations; macOS has no Dynamic Type. For web, use semantic responsive UI with reduced-motion/transparency and opaque fallback.
  • Product visuals use original geometry, camera, material, light, palette, scale, copy-safe space, and no Apple assets; see the production reference for renderer choices.
  • Only call a result generated, rendered, or animated with matching actual evidence. Without an authorized execution path, prepare a handoff and name the missing boundary.
  • Load the web-library reference only for explicit Apple product work; confirm existing-project compatibility and license posture. Do not install, vendor, fetch, or call it native Apple; generic GSAP/logo work stays in its existing lane.
  • Review supplied evidence; prepared guidance is not implementation, accessibility/visual PASS, or certification.
  • Before output and before approval, classify native, web, or marketing intent; use apple-design only for the explicit specialist request.
  • If current source guidance applies, keep its conditional 35% bright-background note; it is not universal. When no renderer is available, do not claim a result; while work is prepared, it is not observed.
  • Never treat web glass as native, never substitute a still for motion, and use only actual evidence after production; without it, the result is not PASS.
  • While evidence is missing, use only a prepared handoff; it is not execution and not a PASS.

Runtime Evidence

Preferred harness for this skill: apple-design.

omh runtime record --skill apple-design --harness apple-design --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 real unresolved user decision or a useful briefing discussion remains, offer one specific, content-linked question. Completed work needs no question; omit unrelated non-action footers and generic offers to continue.

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: skill_view(name='omh-routing', file_path='references/skill-common-rail.md'). Load it when applicable; otherwise name an unavailable capability.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

dag-ulw

무료

Coordinate a large job by splitting it into small tasks with explicit dependencies. Run ready tasks in parallel through Hermes, verify the combined result separately, and repair failures within defined limits before reporting completed work and remaining gaps.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Delivering a feature across multiple modules
  • Coordinating a migration with ordered steps
  • Managing a broad cleanup across separate work areas
rlaope/oh-my-hermes3.6천2026년 10월 23일 업데이트

Guide the addition of a new model generation to oh-my-hermes. The workflow checks model recognition, official specifications, routing rules that select models for tasks, documented pricing, and live access, then validates changes with tests and comparative benchmarks.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Add a new model generation to oh-my-hermes
  • Check API model IDs and dated snapshot recognition
  • Update model selection chains and related documentation
rlaope/oh-my-hermes3.6천2026년 10월 23일 업데이트

Prepare an accessibility audit for an interface using WCAG 2.2 AA, an accessibility standard. Organize evidence for keyboard use, screen readers, contrast, target size, and zoom behavior, then document findings, missing checks, and remediation handoffs.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing checkout accessibility against WCAG 2.2 AA
  • Checking keyboard access and focus order
  • Organizing screen-reader labels and announcement evidence
rlaope/oh-my-hermes3.6천2026년 10월 23일 업데이트

Summarize earned badges, recent unlocks, achievement tiers, and progress using local files from the hermes-achievements plugin. Prepare a badge list or report section while making missing information and the limits of the recorded snapshot clear.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking earned badges
  • Reviewing recently unlocked achievements
  • Finding progress toward the next achievement tier
rlaope/oh-my-hermes3.6천2026년 10월 23일 업데이트

Examine a technical proposal through independent perspectives, challenge their findings, and resolve objections. The result is a structured set of constraints, decisions, risks, and open questions for a separate planning workflow.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing a technical proposal before planning
  • Challenging assumptions behind a migration
  • Organizing risks and unresolved questions
rlaope/oh-my-hermes3.6천2026년 10월 23일 업데이트

Coordinate multiple Hermes agents or profiles through a shared task board. Organize assignments, handoffs, activity updates, blockers, and completion states, while distinguishing planned actions from work supported by observed results.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Coordinate agent roles for a launch checklist
  • Track task handoffs and blockers
  • Prepare work for pickup across profiles or after a restart
rlaope/oh-my-hermes3.6천2026년 10월 23일 업데이트

rlaope의 스킬 모두 보기

이 스킬의 문제 신고