Token导航 LogoToken导航

Agent Skill · 开发规范

visionos-design-guidelines(愿景设计指南)

用于辅助界面设计、视觉规范、排版、配色、布局和交互体验优化。它适合让 Agent 根据产品场景整理页面结构、生成 UI 方案、检查视觉一致性或改进组件层级。使用时需要结合现有品牌、设计系统和用户任务,不应只堆装饰元素;涉及真实页面改动时,应通过截图或浏览器预览检查文本溢出、对齐和响应式表现。

visionos-design-guidelines 是开发规范类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为操作浏览器;许可证信息还不明确,第三方扫描已通过,按安装量在开发规范类的 1,265 个 Skill 里排第 187。

总安装 8,592周安装 351GitHub Stars 350下载 2,780核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:visionos-design-guidelines(愿景设计指南)
来源仓库:https://github.com/ehmo/platform-design-skills
仓库路径:skills/visionos-design-guidelines
安装命令:
npx skills add https://github.com/ehmo/platform-design-skills --skill visionos-design-guidelines
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/ehmo/platform-design-skills --skill visionos-design-guidelines

这个 Skill 是做什么的

开发规范类 Skill 用来统一代码风格、目录结构和评审口径,产出多为检查清单或改写建议。

visionos-design-guidelines 提供 VisionOS 平台的设计规范与交互准则,适合构建一致且合规的沉浸式界面。适用于前端设计与开发规范场景,可辅助生成符合苹果 HIG 的 UI 方案与组件结构。

通过 npx skills add 从 platform-design-skills 仓库安装,集成于主流 Agent 宿主。使用时需结合品牌系统与用户任务,并通过截图预览验证响应式表现与文本溢出问题。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/visionos-design-guidelines

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/ehmo/platform-design-skills --skill visionos-d…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要操作浏览器,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

visionos-design-guidelines 怎么安装?

在终端执行 npx skills add https://github.com/ehmo/platform-design-skills --skill visionos-design-guid…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

visionos-design-guidelines 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

visionos-design-guidelines 需要什么权限?

权限级别是操作浏览器。该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

visionos-design-guidelines 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

visionos-design-guidelines 用的人多吗?

公开数据是累计安装 8,592 次,近一周安装 351 次,下载 2,780 次,GitHub 350 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

visionos-design-guidelines 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发规范类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发规范类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
vercel-react-best-practices

Vercel React 最佳实践 · Codex、Claude

8,490,72025,918操作浏览器MIT通过
web-design-guidelines

网页设计指南 · Codex、Claude

6,686,01625,885需要联网MIT有提醒
remotion-best-practices

Remotion 最佳实践 · Codex、Claude

6,505,6323,027操作浏览器MIT有提醒
supabase-postgres-best-practices

Supabase Postgres 最佳实践 · Codex、Claude

3,175,5232,030需要联网MIT通过
next-best-practices

Next.js 最佳实践 · Codex、Claude

1,848,240841操作浏览器MIT通过
visionos-design-guidelines

愿景设计指南 · 本页

8,592350操作浏览器未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

visionOS Design Guidelines

Comprehensive design rules for Apple Vision Pro based on Apple Human Interface Guidelines. These rules ensure spatial computing apps are comfortable, intuitive, and consistent with platform conventions.


1. Spatial Layout [CRITICAL]

Spatial layout determines user comfort and usability. Poor placement causes neck strain, disorientation, or inaccessible content.

Rules

SL-01: Center content in the field of view. Place primary windows and content directly ahead of the user at eye level. The comfortable vertical viewing range is approximately 30 degrees above and below eye level. Content outside this range requires head movement and causes fatigue.

SL-02: Maintain comfortable distance. Position content at a natural distance from the user, typically 1-2 meters for windows. Content too close feels invasive; content too far is hard to read. The system default placement is approximately 1.5 meters. Respect this unless there is a strong reason to override.

SL-03: Never place content behind the user. Users cannot see content behind them without physically turning around. All UI elements must appear within the forward-facing hemisphere. If content must surround the user, provide clear navigation to rotate or reposition.

SL-04: Respect personal space. Do not place 3D objects or windows closer than arm's length (~0.5 meters) from the user's head. Objects inside personal space cause discomfort and a feeling of intrusion. Direct-touch interactions are the exception, where objects are intentionally within reach.

SL-05: Use Z-depth to establish hierarchy. Elements closer to the user appear more prominent and interactive. Push secondary or background content further back. Use subtle depth offsets (a few centimeters) between layered elements rather than dramatic separation that fragments the interface.

SL-06: Manage multiple windows thoughtfully. When displaying multiple windows, arrange them in a gentle arc around the user rather than stacking or overlapping. Each window should be individually repositionable. Avoid spawning too many simultaneous windows that overwhelm the space.

SL-07: Anchor content to the environment, not the head. Windows and objects should stay fixed in world space as the user moves their head. Head-locked content (content that follows head movement) causes discomfort and motion sickness. Only use head-relative positioning for brief, transient elements like tooltips.


2. Eye & Hand Input [CRITICAL]

visionOS uses indirect interaction as its primary input model: users look at a target and pinch to select. This is fundamentally different from touch or mouse input.

Rules

EH-01: Design for look-and-pinch as the primary interaction. The standard interaction is: user looks at an element (eyes provide targeting), then pinches thumb and index finger together (hand provides confirmation). Design all primary interactions around this model. Users do not need to raise their hands or point at objects.

EH-02: Minimum interactive target size is 60pt. Eye tracking has inherent imprecision. All tappable elements must be at least 60 points in diameter to be reliably targeted by gaze. This is larger than iOS touch targets (44pt). Smaller targets cause frustration and mis-selections.

Correct:

// visionOS — button meeting 60pt minimum
Button(action: confirmAction) {
    Label("Confirm", systemImage: "checkmark")
        .frame(minWidth: 60, minHeight: 60)
        .padding(.horizontal, 16)
}
.buttonStyle(.borderedProminent)

Incorrect:

// visionOS — 32pt button too small for reliable gaze targeting
Button(action: confirmAction) {
    Image(systemName: "checkmark")
        .frame(width: 32, height: 32)  // Below 60pt minimum; unreliable with eye tracking
}

EH-03: Provide hover feedback on gaze. When the user's eyes rest on an interactive element, show a visible highlight or subtle expansion to confirm the element is targeted. This feedback is essential because there is no cursor. Without hover states, users cannot tell what they are about to select.

EH-04: Support direct touch for close-range objects. When 3D objects or UI elements are within arm's reach, allow direct touch interaction (physically reaching out and tapping). Direct touch should feel natural: provide visual and audio feedback on contact. Use direct touch for immersive experiences where it enhances presence.

EH-05: Never track gaze for content purposes. Eye position is used exclusively for system interaction targeting. Do not use gaze direction to infer user interest, change content based on what the user looks at, or record where the user looks. This is a core privacy principle of the platform. The system does not expose raw eye-tracking data to apps.

EH-06: Keep custom gestures simple and intuitive. If you define custom hand gestures beyond the system pinch, ensure they are easy to discover, physically comfortable to perform, and do not conflict with system gestures. Avoid gestures that require sustained hand raising, complex finger patterns, or two-handed coordination for basic actions.

EH-07: Do not require precise hand positioning. Users interact with hands resting naturally in their lap or at their sides. Do not require users to hold their hands in specific positions, reach to specific locations, or maintain sustained gestures. The indirect interaction model exists specifically to reduce physical effort.

EH-08: Confirm intent at the start of the interaction. As soon as the system recognizes gaze target, pinch, drag pickup, or direct touch contact, show a visible state change. Delayed confirmation breaks the eye-hand loop and makes selection feel uncertain.

Spatial Interaction Quick Reference

InteractionMethodUse Case
Tap / SelectLook + pinchButtons, links, list items
ScrollLook + pinch-and-dragLists, long content
ZoomTwo-hand pinchMaps, images, 3D models
RotateTwo-hand twist3D object manipulation
DragLook + pinch-hold-and-moveRepositioning windows
Direct touchReach and tapClose-range 3D objects
Long pressLook + pinch-and-holdContext menus

Target Size Reference

ElementMinimum SizeRecommended Size
Buttons60pt60-80pt
List rows60pt height80pt height
Tab bar items60pt72pt
Close/dismiss60pt60pt
Toolbar items60pt60pt
3D interactive objects60pt equivalentScale to context

3. Windows [HIGH]

Windows in visionOS float in the user's physical space. They use a glass material that blends with the real-world environment.

Rules

WN-01: Use glass material as the default window background. The system glass material dynamically adapts to the user's real-world surroundings, providing a consistent and readable backdrop. Do not replace glass with opaque solid colors unless you have a specific design reason (such as media playback). Glass grounds the interface in the shared space.

WN-02: Maintain standard window controls. Windows include a system-provided window bar at the bottom for repositioning and a close button. Do not hide, override, or replace these controls. Users rely on consistent window management across all apps.

WN-03: Make windows resizable when appropriate. If your content benefits from different sizes (documents, browsers, media), support window resizing. Use the system resize handle. Define reasonable minimum and maximum sizes. Adapt layout responsively as the window resizes.

WN-04: Place the tab bar as a leading ornament (left side). On visionOS, the tab bar (app navigation) is positioned as a vertical ornament on the leading (left) edge of the window, not at the bottom as on iOS. This keeps navigation accessible without consuming window content area. Use SF Symbols for tab icons.

WN-05: Place the toolbar as a bottom ornament. Primary action controls appear in a toolbar ornament anchored to the bottom edge of the window. This positions controls near the user's natural hand resting position and keeps the content area unobstructed.

WN-06: Windows float in space with no fixed screen. There is no fixed display. Windows exist in the user's physical environment. Design content that looks correct when viewed from slight angles and at varying distances. Avoid designs that assume a fixed viewport size or pixel-perfect positioning.


4. Volumes [HIGH]

Volumes display 3D content within a bounded box. They are ideal for 3D models, visualizations, and objects users can examine from multiple angles.

Rules

VL-01: Contain 3D content within the volume bounds. All content must fit within the defined volume dimensions. Content that escapes the bounds will be clipped. Size the volume appropriately for the content it holds and respect the system-enforced limits.

VL-02: Design for viewing from all angles. Users can physically walk around a volume or reposition it. Ensure 3D content looks correct from all viewing angles, not just the front. Avoid flat facades that look like cardboard cutouts from the side.

VL-03: Do not require a specific viewing position. The user may view the volume from above, below, or any side. Content must remain comprehensible regardless of viewing angle. If orientation matters, use visual cues (a base, a label) rather than forcing a specific position.

VL-04: Scale content appropriately for the space. Volumes should be sized relative to their content and the user's environment. A molecular model might be small and held at arm's length. An architectural visualization might fill a table. Consider the context in which users will interact with the volume.

VL-05: Use volumes for self-contained 3D experiences. Volumes are not windows with 3D objects inside them. Use volumes when the 3D content is the primary experience (examining a product model, viewing a 3D chart). Use windows for primarily 2D interfaces that may include some 3D elements.


5. Immersive Spaces [HIGH]

visionOS supports a spectrum of immersion from shared space (apps alongside reality) to full immersion (complete virtual environment).

Rules

IS-01: Start in the Shared Space. Apps launch into the Shared Space by default, where multiple app windows coexist alongside the real world. Only transition to more immersive experiences when the user explicitly requests it. Do not force immersion on launch.

IS-02: Use progressive immersion. Move through immersion levels gradually: Shared Space (windows alongside reality) to Full Space (your app takes over but passthrough remains) to Full Immersion (completely virtual environment). Each step should feel intentional and user-initiated.

IS-03: Always provide an exit path. Users must always be able to return to a less immersive state or exit the experience entirely. The Digital Crown is the system-level escape. Within your app, provide clear controls to reduce immersion. Never trap users in an immersive experience.

IS-04: Use passthrough for safety. In experiences where users might move physically, maintain passthrough of the real environment or provide a guardian boundary. Users need awareness of physical obstacles, other people, and room boundaries. Full immersion is only appropriate when the user is stationary.

IS-05: Dim passthrough gradually. When transitioning to increased immersion, dim the passthrough environment gradually rather than cutting to black. Abrupt visual changes are disorienting. Use smooth, animated transitions between immersion levels.

IS-06: Do not assume room layout or size. Users are in diverse physical spaces. Do not design experiences that require a minimum room size, assume a clear floor area, or expect specific furniture placement. Gracefully adapt to whatever physical space is available.

IS-07: Provide spatial audio cues. In immersive spaces, use spatial audio to help users orient. Sounds should come from the direction of their source in the virtual environment. Audio cues can guide attention and provide feedback without requiring visual focus.


6. Materials & Depth [MEDIUM]

visionOS uses a physically-based material system that responds to real-world lighting. Proper use of materials creates depth hierarchy and ensures readability.

Rules

MD-01: Use the system glass material for UI surfaces. The glass material is the foundation of visionOS UI. It provides depth, translucency, and environmental integration. Use the system-provided glass variants (regular, thin, ultra-thin) rather than custom translucent materials.

MD-02: Specular highlights respond to the environment. Materials in visionOS react to real-world lighting conditions. Design elements that leverage this: subtle specular highlights on interactive elements reinforce their dimensionality. Do not flatten materials with purely matte surfaces.

MD-03: Layer materials to create depth hierarchy. Use lighter/thicker glass for foreground elements and darker/thinner glass for background. Sidebars use a slightly different glass tint than content areas. This layering creates natural visual hierarchy without sharp borders.

MD-04: Apply vibrancy for text readability. Text over glass materials uses vibrancy effects to remain legible regardless of the background environment. Use the system text styles which include appropriate vibrancy. Custom text rendering over glass must account for varying background lightness and color.

MD-05: Use shadows and highlights for elevation. Elements that float above the window surface (popovers, menus, hover states) should cast subtle shadows and show slight specular highlights on their upper edges. These depth cues help users understand the spatial relationship between interface layers.

MD-06: Avoid fully opaque backgrounds in shared space. Opaque surfaces in the shared space create visual holes in the environment. Use translucent glass materials that let the environment show through. Exceptions include media playback (video, photos) where an opaque background improves the viewing experience.


7. Ornaments [MEDIUM]

Ornaments are UI controls that attach to the edges of windows, floating partially outside the window bounds. They provide toolbars, navigation, and contextual actions.

Rules

OR-01: Attach controls as ornaments rather than inline. Toolbars, tab bars, and persistent action buttons belong as ornaments, not embedded within the window content area. Ornaments keep the content area clean and establish a clear spatial hierarchy between controls and content.

OR-02: Place primary actions in the bottom ornament. The bottom edge ornament is the primary location for action controls (play/pause, formatting tools, share). This position is ergonomically accessible and visually prominent without obscuring content.

OR-03: Place navigation in the leading (left) ornament. App-level navigation (tab bar equivalent) attaches to the leading edge of the window. This keeps navigation persistent and accessible while leaving the content area and bottom ornament for contextual controls.

OR-04: Do not occlude window content with ornaments. Ornaments extend outward from the window edge, not inward. They should not cover or overlap the window's content area. Size ornaments appropriately so they remain functional without becoming visually dominant over the content.

OR-05: Show ornaments contextually when appropriate. Not all ornaments need to be visible at all times. Toolbars can appear on hover (when the user looks at the window) and fade when the user looks away. This keeps the interface clean while maintaining discoverability.

OR-06: Use standard ornament styling. Ornaments use the same glass material system as windows but at a slightly different depth. Use system-provided ornament containers rather than custom floating UI. This ensures visual consistency with other visionOS apps.

OR-07: Keep essential controls discoverable. Use ornaments for commands users must revisit repeatedly, such as navigation, playback, or primary actions. Do not hide essential controls behind memorized gestures or hover-only affordances.


8. Accessibility [CRITICAL]

visionOS supports VoiceOver, Switch Control, and pointer control alternatives. Spatial UI must be navigable without relying solely on eye and hand input.

Rules

ACC-01: Every interactive element must have a meaningful accessibility label. Buttons, controls, and 3D objects that users can interact with must have labels VoiceOver can announce. Do not rely on visual appearance or position alone.

ACC-02: VoiceOver must be able to reach all interactive elements. Ensure the accessibility tree covers all focusable controls. Custom RealityKit entities that are interactive must be registered in the accessibility hierarchy.

ACC-03: Support pointer control and Switch Control alternatives. Not all users can use eye tracking and hand pinch. Ensure the app is fully navigable via alternative input methods such as head pointer, Switch Control, or keyboard navigation.

ACC-04: Respect Reduce Motion. Spatial animations, immersive transitions, and parallax effects must be disabled or reduced when Reduce Motion is enabled. Abrupt motion in a spatial environment can cause disorientation.

@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    Model3D(named: "SceneObject")
        .rotation3DEffect(reduceMotion ? .zero : rotation, axis: (0, 1, 0))
}

ACC-05: Respond to Bold Text. When the user enables Bold Text, custom-rendered text in visionOS must adapt. SwiftUI dynamic type styles handle this automatically; custom rendering must check UIAccessibility.isBoldTextEnabled or use @Environment(\.legibilityWeight) to detect and apply heavier weights.

ACC-06: Respond to Increase Contrast. When the user enables Increase Contrast, custom colors must provide higher-contrast variants. Use @Environment(\.colorSchemeContrast) in SwiftUI to detect .increased and substitute higher-contrast color values for text and UI elements rendered against glass or environment backgrounds.


Evaluation Checklist

Use this checklist to evaluate a visionOS design or implementation.

Spatial Layout

  • Primary content centered in forward field of view
  • Content placed at comfortable distance (1-2m for windows)
  • No content placed behind the user
  • Personal space respected (nothing closer than ~0.5m)
  • Z-depth used meaningfully for hierarchy
  • Multiple windows arranged in arc, not stacked
  • Content anchored to world space, not head-locked

Eye & Hand Input

  • All interactions work with look-and-pinch
  • All interactive targets >= 60pt
  • Hover states visible on all interactive elements
  • Direct touch supported for close-range objects
  • No gaze tracking for content or analytics purposes
  • Custom gestures are simple and discoverable
  • No sustained hand-raising required

Windows

  • Glass material used as default background
  • Standard window bar and close button present
  • Tab bar positioned as leading ornament
  • Toolbar positioned as bottom ornament
  • Layout adapts to different window sizes
  • Content designed for floating in space

Volumes

  • Content contained within volume bounds
  • Content looks correct from all viewing angles
  • No specific viewing position required
  • Scale appropriate for content and context

Immersive Spaces

  • App starts in Shared Space
  • Immersion increases progressively
  • Clear exit path always available
  • Passthrough maintained where safety requires it
  • Transitions between immersion levels are smooth
  • No assumptions about room size or layout

Materials & Depth

  • System glass material used for UI surfaces
  • Material layering creates depth hierarchy
  • Text uses vibrancy for readability over glass
  • Shadows and highlights indicate elevation
  • No fully opaque surfaces in shared space (except media)

Ornaments

  • Controls attached as ornaments, not inline
  • Primary actions in bottom ornament
  • Navigation in leading ornament
  • Ornaments extend outward, not over content
  • Standard ornament styling used

Accessibility

  • Bold Text preference respected (SwiftUI handles automatically; custom text checks legibilityWeight or UIAccessibility.isBoldTextEnabled)
  • Increase Contrast preference respected (custom colors provide higher-contrast variants via colorSchemeContrast)
  • All interactive elements and 3D objects have meaningful accessibility labels
  • App is fully navigable via head pointer or Switch Control (not solely eye-and-pinch)
  • Spatial animations and immersive transitions disabled or reduced when Reduce Motion is enabled
  • Interactive RealityKit entities are registered in the accessibility hierarchy

Anti-Patterns

These are common mistakes in visionOS design. Avoid them.

Anti-PatternProblemCorrect Approach
Head-locked UICauses motion sickness, feels claustrophobicAnchor UI to world space
Tiny tap targetsEye tracking cannot reliably target < 60ptMinimum 60pt interactive targets
No hover statesUsers cannot tell what is interactiveAlways show highlight on gaze
Opaque windows in shared spaceCreates visual holes in environmentUse system glass material
Forced full immersionDisorienting, traps usersStart in shared space, progressive immersion
Content behind userInvisible, requires full body rotationKeep content in forward hemisphere
Gaze-driven contentPrivacy violation, feels surveilledUse gaze only for system targeting
Flat 3D volumesLooks like cardboard cutout from sideDesign for all viewing angles
Inline toolbarsWastes content space, breaks conventionsUse ornaments for controls
Small room assumptionsFails in tight spacesAdapt to available physical space
Abrupt immersion changesDisorienting, breaks presenceGradual transitions with animation
Sustained arm raisingPhysical fatigue in minutesDesign for hands resting at sides
Custom window chromeBreaks platform consistencyUse system window controls
Z-fighting layersVisual flicker, unclear hierarchyUse intentional depth offsets

平台分布

Codex

36.11%
按下载量换算1,004

Claude

30.61%
按下载量换算851

Cursor

19.86%
按下载量换算552

Gemini CLI

10.72%
按下载量换算298

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills