@design-ai/cli 4.55.0

package/skills/slide-deck-author/PLAYBOOK.md

@@ -0,0 +1,198 @@
+# slide-deck-author — playbook
+
+Design and outline a slide deck (talk / pitch / reading deck). Outputs slide-by-slide content + design specs that a human or framework (Keynote, Figma Slides, reveal.js / Slidev) can render.
+
+## When to use
+
+- "Make a 10-min talk on X"
+- "Pitch deck for our seed round"
+- "Internal review deck for the new feature"
+- "Conference talk on design tokens"
+
+## Inputs (ask if missing)
+
+1. **Type**:
+   - **Talk deck** — presented live, supports speaker
+   - **Pitch / sales deck** — sent + presented
+   - **Reading deck** — sent only, read alone (warning: probably should be a doc)
+2. **Topic + thesis** — what's the deck about? What's the one-line takeaway?
+3. **Length** — minutes (talk) or slide count (pitch).
+4. **Audience** — who's watching/reading?
+5. **Brand** — color, font, logo, voice (or link to brand kit).
+6. **Locale** — Korean / English / both.
+
+## Steps
+
+### 1. Pick the archetype
+
+If unsure, decision rules from [`knowledge/patterns/slide-deck-design.md`](../../knowledge/patterns/slide-deck-design.md):
+
+| Will it be sent + read alone? | Should be a doc, not a deck |
+| Will it support a live presenter? | Talk deck (low density) |
+| Will it be both sent + presented? | Pitch deck (medium density) |
+
+If user insists on a "reading deck": warn that documents render better, then proceed.
+
+### 2. Draft the outline
+
+Slide-by-slide. Each entry has:
+- Slide number
+- Title (the message, not the topic)
+- Visual (chart / image / mockup / nothing)
+- Body text or speaker notes
+
+For **talk deck** (10–25 slides typical):
+
+```
+1. Title slide — "Design Tokens, From First Principles"
+2. Hook — the audience problem ("designers and devs say different colors")
+3. Personal credibility (~5 sec, optional)
+4. Argument 1 — "Tokens unify the language"
+   - Chart / before-after image
+5. Argument 2 — "Three-tier architecture"
+   - Diagram
+6. Argument 3 — ...
+...
+N. Conclusion / call to action
+```
+
+For **pitch deck** — Sequoia-style 12 slides:
+```
+1. Hero (company + tagline)
+2. Problem
+3. Solution
+4. Why now
+5. Product (demo screenshot)
+6. Traction (chart)
+7. Business model
+8. Competition
+9. Team
+10. Financials / Ask
+```
+
+### 3. Headline-as-message
+
+For each slide, the title states the **takeaway**, not the topic.
+
+| Topic title (bad) | Message title (good) |
+| --- | --- |
+| "Revenue" | "Revenue tripled in Q4" |
+| "Architecture" | "We chose 3-tier for upgrade safety" |
+| "Onboarding flow" | "Onboarding completes in 30 seconds" |
+| "Tokens" | "Tokens cut design-dev rework by 40%" |
+
+If the audience reads only the slide titles, they get the deck's argument.
+
+### 4. Choose visuals per slide
+
+For each slide, pick **one** primary visual:
+- Chart (per [`knowledge/patterns/chart-color-encoding.md`](../../knowledge/patterns/chart-color-encoding.md))
+- Screenshot of product (with annotations)
+- Diagram (architecture, workflow, hierarchy)
+- Photo (for emotion / human moment, sparingly)
+- Just text (when the message is the visual)
+
+Don't combine multiple visuals on one slide. The visual proves the title.
+
+### 5. Apply visual / brand
+
+Cite [`knowledge/patterns/brand-identity.md`](../../knowledge/patterns/brand-identity.md):
+- Logo top-left or bottom-right (small).
+- Brand color for accents (highlights, callouts, chart series).
+- One typographic family (display + body if pairing).
+- Background: neutral white or branded solid (no gradient noise).
+
+For Korean-audience decks, cite [`knowledge/i18n/korean-document-style.md`](../../knowledge/i18n/korean-document-style.md):
+- Pretendard or similar.
+- Slightly more text density than Western decks (Korean business convention).
+- Numbered hierarchical sections.
+
+### 6. Output spec
+
+Two outputs:
+
+#### A. Outline markdown (for review)
+
+```markdown
+# Deck: [title]
+
+## Meta
+- Type: talk deck
+- Length: 10 min (~15 slides)
+- Audience: senior designers
+- Brand: design-ai
+
+## Outline
+
+### 1. Title
+- Visual: company logo + tagline
+- Notes: [what speaker says]
+
+### 2. Hook — "Why design tokens matter"
+- Visual: side-by-side photo (chaotic palette vs unified)
+- Body text: none — image speaks
+- Notes: [opening anecdote]
+
+### 3. Argument 1 — "Tokens unify the design-dev handoff"
+- Visual: chart of design-dev rework hours, before vs after tokens
+- Body text: "Rework hours: -40% after token rollout"
+- Notes: [story behind the chart]
+
+...
+```
+
+#### B. Render-ready format (optional — based on tool)
+
+For Figma Slides / Keynote: outline + visual spec is enough; designer renders.
+
+For reveal.js / Slidev (markdown-based decks): generate the actual `.md` file:
+
+```markdown
+---
+theme: default
+title: Design Tokens
+---
+
+# Design Tokens
+From First Principles
+
+---
+
+# The problem
+[image: chaotic-palette.png]
+
+---
+
+# Tokens unify the language
+[chart: rework-hours.png]
+```
+
+## Verification phase (run before declaring done)
+
+- [ ] Did I pick the right archetype (warn if reading-deck)?
+- [ ] Is the title of every slide a **message** (not a topic)?
+- [ ] Each slide has one visual + one message — no mixed?
+- [ ] Brand applied (logo, color, type)?
+- [ ] Slide count appropriate for length (15-25 for 20-min talk)?
+- [ ] If Korean: voice level consistent (~합니다 vs ~해요)?
+- [ ] Speaker notes for live talks?
+- [ ] No 3D charts / clipart / stock photos of people pointing at laptops?
+
+## Source files this skill reads
+
+- [`knowledge/patterns/slide-deck-design.md`](../../knowledge/patterns/slide-deck-design.md) — full deck rules
+- [`knowledge/patterns/brand-identity.md`](../../knowledge/patterns/brand-identity.md) — brand application
+- [`knowledge/patterns/chart-color-encoding.md`](../../knowledge/patterns/chart-color-encoding.md) — charts on slides
+- [`knowledge/patterns/document-typography.md`](../../knowledge/patterns/document-typography.md) — when reading-deck → doc
+- [`knowledge/i18n/korean-document-style.md`](../../knowledge/i18n/korean-document-style.md)
+- [`knowledge/patterns/information-architecture.md`](../../knowledge/patterns/information-architecture.md) — section structure for long decks
+
+## Done when
+
+- Outline markdown delivered, slide-by-slide.
+- Each slide title is a message.
+- Each slide has one visual concept + body text.
+- Brand applied consistently.
+- Speaker notes for live decks.
+- (Optional) render-ready format for declarative tools (reveal.js / Slidev).
+- Verification phase passes.

package/skills/slide-deck-author/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: slide-deck-author
+description: Design and outline a slide deck (talk / pitch / reading deck). Picks archetype, drafts slide-by-slide content with message-led titles, applies brand, outputs outline + render-ready markdown for declarative deck tools. Korean-aware.
+---
+
+See [PLAYBOOK.md](PLAYBOOK.md).

package/skills/spatial-designer/PLAYBOOK.md

@@ -0,0 +1,238 @@
+# spatial-designer — playbook
+
+Design and spec spatial / AR / VR / MR experiences. Output is a markdown spec covering platform, anchoring, locomotion, UI elements, comfort, and accessibility.
+
+## When to use
+
+- "Design a Vision Pro productivity app."
+- "Spec the locomotion for our VR game."
+- "Plan a mobile AR product visualization."
+- "Build a HoloLens training app."
+- "Design a WebXR experience for our website."
+
+## Inputs (ask if missing)
+
+1. **Mode** — VR (immersive) / AR (mobile) / MR (passthrough headset) / WebXR / hybrid.
+2. **Platform** — Vision Pro / Quest / HoloLens / iOS ARKit / Android ARCore / WebXR.
+3. **Use case** — productivity / game / training / social / cinema / commerce AR.
+4. **Audience** — first-time VR / experienced / Korean / international.
+5. **Session length** — minutes (mobile AR) / hours (productivity).
+6. **Locomotion needed?** — none (room-scale only) / teleport / smooth / hybrid.
+7. **Input methods** — hand tracking / controllers / gaze / voice / mixed.
+8. **Existing brand voice** — for visual / interaction style.
+
+## Steps
+
+### 1. Pick the mode + platform
+
+| Mode | Read |
+| --- | --- |
+| VR (immersive) | [`vr-patterns.md`](../../knowledge/spatial/vr-patterns.md) |
+| AR (mobile / headset MR) | [`ar-patterns.md`](../../knowledge/spatial/ar-patterns.md) |
+| All — UI elements | [`spatial-ui-elements.md`](../../knowledge/spatial/spatial-ui-elements.md) |
+| All — comfort + a11y | [`comfort-and-accessibility.md`](../../knowledge/spatial/comfort-and-accessibility.md) |
+
+Always read [`spatial-design-fundamentals.md`](../../knowledge/spatial/spatial-design-fundamentals.md).
+
+### 2. Spec the spatial geometry
+
+| Aspect | Decide |
+| --- | --- |
+| Coordinate system | Right-handed (Unity) / left-handed (Unreal) / per platform |
+| Default user height | 1.7m typical adult; allow calibration |
+| Comfort distance for primary UI | 1.2-1.5m |
+| Eye-level reference | 0° (eye level), -10° (slightly below for reading) |
+| Field of view design | ±30° comfort zone |
+
+### 3. Spec anchoring
+
+For each UI element:
+- **World-locked** (fixed in space).
+- **Wrist-locked** (Vision Pro Home, quick menu).
+- **Hand-locked** (held tools).
+- **Head-locked** (sparingly — reticle, brief alerts).
+- **Object-locked** (AR — pinned to recognized object).
+- **Image-locked** (AR — triggered by marker).
+
+Document each: when, where, why.
+
+### 4. Spec locomotion (VR / immersive)
+
+| Mode | Default for |
+| --- | --- |
+| Room-scale only | Stationary games (Beat Saber, vehicle sims) |
+| Teleport | First-time users; accessible default |
+| Snap turn | New + most users |
+| Smooth move (with comfort options) | Hardcore VR; opt-in |
+| Smooth turn | Opt-in advanced |
+| Hybrid | Most action games |
+
+Apply comfort vignette, fade transitions, and frame-rate guarantees (90+ fps).
+
+### 5. Spec input methods
+
+For each interaction:
+- **Hand tracking** (pinch, point, grab, push).
+- **Controllers** (trigger, grip, joystick, buttons).
+- **Gaze + pinch** (Vision Pro signature).
+- **Voice commands**.
+- **Eye tracking** (where supported).
+- **Hardware inputs** (face touch, head tap).
+
+Don't make any single input mode mandatory. Provide alternatives.
+
+### 6. Spec UI elements
+
+For each panel / button / menu:
+- **Anchoring** mode.
+- **Distance + size** (visual angle preferred).
+- **Billboarding** behavior.
+- **Visual states** (idle / hover / pressed / selected).
+- **Audio feedback** for state changes.
+- **Occlusion** (real / virtual).
+
+Use `SpatialPanel` primitive where applicable.
+
+### 7. Plan comfort options
+
+Comfort options menu (mandatory for VR):
+
+- Locomotion mode (teleport / smooth / hybrid).
+- Turn mode (snap / smooth) + angle.
+- Comfort vignette strength.
+- Smooth move speed.
+- Camera motion control (allow / limit / none).
+- Reduce flashing / particles.
+
+### 8. Plan accessibility
+
+- **Vision**: large text option, high contrast, color-blind, screen reader / VoiceOver.
+- **Hearing**: subtitles + visual sound indicators.
+- **Motor**: one-handed mode, voice nav, dwell-click.
+- **Cognitive**: clear instructions, pause anywhere, save often.
+- **Photosensitive**: no flashing > 3Hz; reduce particles option.
+- **Mobility**: seated mode, smaller play area option, auto-walk.
+
+### 9. Plan onboarding (first-run)
+
+For users new to spatial:
+- **Calibration** (eye height, IPD, hand tracking).
+- **Tutorial** for unique gestures (pinch, teleport).
+- **Comfort defaults** (most accessible).
+- **Skip** for repeat users.
+
+For AR mobile:
+- **Surface detection** prompt.
+- **Permission grant** for camera.
+- **Visual instructions** to scan environment.
+
+### 10. Korean / regional
+
+| Aspect | Notes |
+| --- | --- |
+| Korean text | Pretendard / NanumSquare; ~1.5× Latin equivalent for readability at low PPD |
+| Voice / TTS | Korean voice for assistant; 해요체 default |
+| Privacy | 개인정보보호법 — disclose camera + body data use |
+| Galaxy XR (upcoming) | Samsung XR ecosystem when launches |
+| Cross-platform | Web XR or Unity / Unreal multi-platform |
+
+### 11. Performance
+
+- 90Hz minimum (VR); 120Hz preferred.
+- 60Hz for mobile AR.
+- Frame budget per device.
+- Foveated rendering where supported.
+- Polygon / texture budgets per platform.
+- Battery / heat for mobile AR — limit session length.
+
+### 12. Output
+
+```markdown
+# Spatial design spec: <experience name>
+
+> Mode: <VR / AR / MR / WebXR>
+> Platform: <Vision Pro / Quest / HoloLens / iOS ARKit / WebXR>
+> Use case: <productivity / game / training / social / cinema / commerce AR>
+> Audience: <first-time / experienced / Korean / international>
+> Session length: <minutes / hours>
+
+## Spatial geometry
+<coordinate system, height, comfort distance, FOV>
+
+## Anchoring
+<per UI element: world / wrist / hand / head / object>
+
+## Locomotion (if VR)
+<modes, defaults, comfort options>
+
+## Input methods
+<hand / controller / gaze / voice; alternatives for accessibility>
+
+## UI elements
+<panels, buttons, menus with sizing + states>
+
+## Comfort options
+<locomotion / turn / vignette / motion / flashing>
+
+## Accessibility
+<vision / hearing / motor / cognitive / photosensitive / mobility>
+
+## Onboarding
+<calibration / tutorial / skip>
+
+## Korean / regional (if applicable)
+<text, voice, privacy, Galaxy XR>
+
+## Performance budget
+<fps, polygons, textures, battery>
+
+## UI components needed
+<reference SpatialPanel, SpatialLocomotion, etc>
+
+## Don't
+<2-3 specific misuses>
+```
+
+## Source files this skill reads
+
+- [`knowledge/spatial/spatial-design-fundamentals.md`](../../knowledge/spatial/spatial-design-fundamentals.md)
+- [`knowledge/spatial/vr-patterns.md`](../../knowledge/spatial/vr-patterns.md)
+- [`knowledge/spatial/ar-patterns.md`](../../knowledge/spatial/ar-patterns.md)
+- [`knowledge/spatial/spatial-ui-elements.md`](../../knowledge/spatial/spatial-ui-elements.md)
+- [`knowledge/spatial/comfort-and-accessibility.md`](../../knowledge/spatial/comfort-and-accessibility.md)
+- [`knowledge/game-ui/game-accessibility.md`](../../knowledge/game-ui/game-accessibility.md) — broader a11y
+- [`knowledge/motion/principles.md`](../../knowledge/motion/principles.md) — motion
+- [`knowledge/i18n/korean-typography.md`](../../knowledge/i18n/korean-typography.md) — Hangul fonts
+- [`examples/component-spatial-panel.md`](../../examples/component-spatial-panel.md)
+- [`examples/component-spatial-locomotion.md`](../../examples/component-spatial-locomotion.md)
+
+## Verification phase (run before declaring done)
+
+- [ ] Is the mode (VR / AR / MR / WebXR) explicit?
+- [ ] Is the platform (Vision Pro / Quest / etc) explicit?
+- [ ] Are anchoring choices documented per UI element?
+- [ ] If VR: are locomotion options + comfort defaults specified?
+- [ ] Are input methods + alternatives documented?
+- [ ] Are UI elements specified with sizing + states + audio?
+- [ ] Are comfort options addressed (locomotion, turn, vignette, motion, flashing)?
+- [ ] Is accessibility addressed across vision / hearing / motor / cognitive / photosensitive / mobility?
+- [ ] Is performance budget (fps, polygons) explicit?
+- [ ] Is onboarding planned?
+- [ ] If Korean: is Korean text size + 개인정보보호법 addressed?
+- [ ] Does "Don't" catch 2-3 specific misuses?
+
+## Done when
+
+- One markdown spec, < 500 lines.
+- Mode + platform + use case + audience explicit.
+- Spatial geometry defined.
+- Anchoring per UI element.
+- Locomotion (if VR).
+- Input methods.
+- UI elements with states + sizing.
+- Comfort options.
+- Accessibility plan.
+- Performance budget.
+- Onboarding plan.
+- "Don't" section.
+- Verification passes.

package/skills/spatial-designer/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: spatial-designer
+description: Design and spec spatial / AR / VR / MR experiences. Picks platform (Vision Pro / Quest / HoloLens / mobile AR / WebXR), anchoring (world / wrist / hand / head), locomotion (teleport / smooth / snap turn), comfort options, accessibility. Korean Galaxy XR and KR market context.
+---
+
+See [PLAYBOOK.md](PLAYBOOK.md).

package/skills/ux-audit/PLAYBOOK.md

@@ -0,0 +1,142 @@
+# ux-audit — playbook
+
+Audit a screen, flow, or page against UX best practices and accessibility. Output is a prioritized list of issues with severity, citation, and fix recommendation.
+
+## When to use
+
+- "Review this signup flow."
+- "What's wrong with our settings page?"
+- "Audit the checkout."
+- Pre-ship gate before release.
+
+## Inputs (ask if missing)
+
+1. **Artifact** — screenshot, Figma link, live URL, or HTML/code.
+2. **Context** — who the user is, what they're trying to accomplish, what step in the flow this is.
+3. **Platform** — web, iOS, Android, responsive web. Affects platform conventions.
+4. **Specific concerns?** — sometimes the user already suspects an area; deep-dive that.
+
+## Steps
+
+### 1. Establish the user goal
+
+Before evaluating, name the **primary user goal** for the artifact in one sentence. Every issue is rated against whether it helps or hurts that goal.
+
+### 2. Walk the issue catalog
+
+Open [`knowledge/patterns/ux-guidelines.md`](../../knowledge/patterns/ux-guidelines.md). For each category that applies (Navigation, Forms, Feedback, Loading, etc.), check the artifact against the listed do/don't pairs. Mark each as: **pass / fail / N/A**.
+
+### 3. Run the a11y pass
+
+For every interactive element on the artifact:
+- Is it reachable by keyboard? (Cite [`knowledge/a11y/keyboard-and-focus.md`](../../knowledge/a11y/keyboard-and-focus.md))
+- Does the focus indicator clear 3:1 contrast and 2px thickness?
+- Is the touch target ≥ 44×44 (mobile) or ≥ 24×24 (web AA)?
+- Does it have a label that a screen reader can announce?
+
+For every text element:
+- Does it clear 4.5:1 (body) or 3:1 (large)? Cite [`knowledge/a11y/contrast.md`](../../knowledge/a11y/contrast.md).
+- Is meaning conveyed by anything other than color alone?
+
+### 4. Check the visual style consistency
+
+- Is spacing on the 4-px grid?
+- Are font sizes from a defined scale, or random?
+- Are colors from a defined palette, or one-offs?
+- Are corner radii consistent across components on the page?
+- Are interactive elements visually distinct from static elements?
+
+### 5. Check the cognitive load
+
+- How many decisions does the user face at once?
+- Is the primary action visually dominant? (1 per screen.)
+- Are required fields marked, errors specific, success acknowledged?
+- Is the back/escape path obvious?
+- Reading load: can the user accomplish the goal without reading more than ~50 words?
+
+### 6. Check the platform conventions
+
+| Platform | Watch for |
+| --- | --- |
+| iOS | Native back gesture, system fonts, sheet presentation, safe-area, dynamic type |
+| Android | Material elevation, FAB placement, system-back, gesture nav inset |
+| Web | Browser back behavior, deep linking, copy-pastable URLs, refresh resilience |
+| Responsive web | Touch on touchscreens, hover only as enhancement |
+
+### 7. Score each issue
+
+| Severity | Definition | Action |
+| --- | --- | --- |
+| 🔴 Critical | Blocks the goal OR fails WCAG AA | **Must fix before ship.** |
+| 🟠 High | Significantly slows or confuses users | **Fix this cycle.** |
+| 🟡 Medium | Inconsistency, minor friction | **Schedule.** |
+| 🟢 Low | Polish, suggestion | **Backlog.** |
+
+A11y failures (contrast < 4.5:1 for body text, missing labels, inaccessible keyboard paths) are **always Critical**, regardless of how minor they look.
+
+### 8. Output
+
+A structured report:
+
+```markdown
+# UX Audit: <artifact name>
+
+> User goal: <one sentence>
+> Platform: <platform>
+> Reviewed: <date>
+
+## Summary
+<3 bullets: what works, what's at risk, top recommendation>
+
+## Critical (n)
+1. **<title>** — <where>
+   - Issue: <what's wrong>
+   - Why: <impact on user>
+   - Fix: <specific recommendation>
+   - Reference: <citation to knowledge/ or WCAG>
+
+## High (n)
+...
+
+## Medium (n)
+...
+
+## Low (n)
+...
+
+## Things that work well
+<2–4 bullets, genuine praise — keeps the report constructive>
+```
+
+## Source files this skill reads
+
+- [`knowledge/patterns/ux-guidelines.md`](../../knowledge/patterns/ux-guidelines.md)
+- [`knowledge/a11y/contrast.md`](../../knowledge/a11y/contrast.md)
+- [`knowledge/a11y/keyboard-and-focus.md`](../../knowledge/a11y/keyboard-and-focus.md)
+- [`knowledge/colors/color-theory.md`](../../knowledge/colors/color-theory.md)
+- [`knowledge/typography/type-scale-fundamentals.md`](../../knowledge/typography/type-scale-fundamentals.md)
+- [`knowledge/layout/spacing-and-grid.md`](../../knowledge/layout/spacing-and-grid.md)
+- [`knowledge/patterns/form-design.md`](../../knowledge/patterns/form-design.md) — when auditing forms
+- [`knowledge/patterns/list-and-feed.md`](../../knowledge/patterns/list-and-feed.md) — when auditing feeds/lists
+- [`knowledge/patterns/mobile-navigation.md`](../../knowledge/patterns/mobile-navigation.md) — when auditing mobile nav
+- [`knowledge/i18n/korean-product-conventions.md`](../../knowledge/i18n/korean-product-conventions.md) — Korean apps
+
+## Verification phase (run before declaring done)
+
+- [ ] Did I name the user goal at the top of the report?
+- [ ] Does every issue have a citation to a knowledge/ file or WCAG section?
+- [ ] Does every CRITICAL issue cite a specific WCAG criterion (e.g., 1.4.3, 2.4.7)?
+- [ ] Are issues sorted within each severity (most blocking first)?
+- [ ] Did I include a "things that work well" section (constructive balance)?
+- [ ] Is each fix recommendation actionable (not "consider improving")?
+- [ ] If platform-specific (mobile / KR): did I check the relevant convention file?
+- [ ] Are duplicate issues merged (not listed in both a11y and UX)?
+
+## Done when
+
+- One report file with summary + 4 severity sections + "things that work well".
+- Every issue has: where, what, why, fix, citation.
+- Every Critical issue has at least one knowledge/ or WCAG citation.
+- The report names the user goal up top.
+- The report is **specific** — no "could be improved" without a stated alternative.
+- The verification phase checklist passes.

package/skills/ux-audit/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: ux-audit
+description: Audit a screen, flow, or page against UX best practices and WCAG accessibility. Output is a prioritized issue list with severity, citation, and specific fix.
+---
+
+See [PLAYBOOK.md](PLAYBOOK.md).