/design-spatial

description: "Design a spatial computing interface for visionOS, Vision Pro, or WebXR — depth hierarchy, window type, ornament placement, spatial typography, and interaction model."
argument-hint: "[app type: productivity|media|utility|game] [platform: visionos|webxr] [brief]"
allowed-tools: ["Read", "Write", "mcp__*"]

/design-spatial

You are designing a complete spatial computing interface spec. Your output is a single structured document covering window type selection, depth hierarchy, ornament placement, spatial typography, and interaction model — all calibrated to the parsed app type, platform, and brief.

Input

Arguments: **$ARGUMENTS**

Parse the following from `$ARGUMENTS`:

• **App type**: productivity / media / utility / game (default: productivity)
• **Platform**: visionOS / WebXR (default: visionOS)
• **Brief**: any description of the app's purpose, primary task, or audience

---

Step 1: Load Knowledge Base

Read `${CLAUDE_PLUGIN_ROOT}/skills/design/references/spatial-designer.md` to apply the full Spatial Designer knowledge base to every section below.

**MCP Fallback**: If the file cannot be read, proceed using inline knowledge. The inline knowledge for this command covers: visionOS window types (Window 2D for productivity, Volume for 3D objects, Immersive Space Full/Mixed for experiences); depth layers (Background 2–4m, Content 1–2m, Foreground 0.5–1m, Overlay <0.5m); ornament system (attachmentAnchor positioning, narrower than window, max 1 bar per edge); spatial typography (distance-size formula: recommended = 44pt × distance_m; SF Pro for visionOS, system-ui for WebXR; minimum weight Regular 400); gaze+pinch primary input for visionOS with 44pt minimum targets; vestibular comfort rules (no automatic locomotion, fade transitions 0.3s, stable horizon, no oscillating motion); eye strain prevention (no pure white backgrounds, WCAG AA minimum, rest areas in layout); dynamic type capped at .accessibility2 for body, .accessibility3 for display.

---

Step 2: Generate the Spec

Produce all five sections below as a single continuous output. Do not pause or ask for confirmation between sections.

---

Section 1: Window Type Selection

Based on the parsed app type and brief, recommend the primary window type from the visionOS or WebXR model.

For **visionOS**, select from:

| Type | Use Case | |------|----------| | Window (2D) | Productivity, content browsing, flat UI — default for most apps | | Volume | 3D objects, data models, physical simulations — when 3D nature is the point | | Immersive Space (Full) | Total immersive experiences, games, virtual tours | | Immersive Space (Mixed) | AR overlay on real objects, spatial annotations, instruction apps |

For **WebXR**, select the session type:

| Type | Use Case | |------|----------| | `inline` | 3D in browser window — always-available baseline; design must work fully here | | `immersive-vr` | Full VR takeover; requires headset | | `immersive-ar` | Mixed reality via camera passthrough; requires AR-capable device |

Provide one rationale sentence explaining why this window type fits the parsed brief.

For **multi-surface apps** (apps that need more than one window type): specify the primary type and list companion types with their roles (e.g., primary: Window 2D for task surface; companion: Volume for 3D data preview).

---

Section 2: Depth Hierarchy Document

Produce a 4-layer spec table assigning content to each physical depth zone. Apply the distance-size formula where sizing is specified: `recommended_size = 44pt × distance_m`.

| Layer | Distance Range | Semantic Role | Element Types | Sizing Constraint | Interaction Method | |-------|---------------|---------------|---------------|-------------------|--------------------| | **Background** | 2–4m | Ambient context, world-locked persistent info | Environment cues, ambient data, decorative world elements | No fine interactive targets at this range — targeting accuracy degrades beyond 3m | Passive / gaze attention only | | **Content** | 1–2m | Primary UI, main task surface | [Derive from brief: primary panels, task interfaces, main content] | Recommended: 44–88pt (44pt × 1–2m); minimum: 36–70pt | Gaze + pinch (visionOS); controller ray-cast or hand tracking (WebXR) | | **Foreground** | 0.5–1m | Active selections, quick actions, notifications | [Derive from brief: toolbars, active state panels, notifications] | Recommended: 22–44pt (44pt × 0.5–1m); minimum: 20–36pt; tap targets ≥44pt | Direct manipulation within arm's reach; gaze + pinch for visionOS | | **Overlay** | <0.5m | Modals, critical alerts, focus-required interactions | Confirmation dialogs, error states, critical prompts only | Use sparingly — content this close triggers eye convergence strain if sustained | Explicit confirmation required before dismissal |

For each layer, note any app-specific elements derived from the parsed brief.

**Layer assignment rules to apply:**

• Content Layer is where users spend most time — optimize for density and legibility here
• Never place critical interactive controls in the Background Layer
• Notifications always go in the Foreground Layer
• Overlay Layer should be used sparingly; sustained near-field content causes convergence strain

---

Section 3: Ornament Placement Spec

Specify ornaments for each relevant window edge. Ornaments extend the window's interactive surface without cluttering the primary content area.

**Ornament rules:**

• Width must be narrower than the host window width
• Position via `attachmentAnchor` parameter of the `ornament()` modifier — do not use fixed point offsets, which vary by window size
• The system automatically places ornaments slightly in front of the window plane — do not specify a fixed Z depth offset
• Maximum 1 ornament bar per window edge
• Primary actions belong inside the window; ornaments are for secondary controls

| Window Edge | Ornament Type | Content | Width Constraint | Attachment Anchor | |-----------