@design-ai/cli 4.55.0

package/commands/motion-design.md

@@ -0,0 +1,54 @@
+---
+description: Design and spec motion for a screen, component, or page — picks tool, durations, easings, and writes a developer-ready motion spec. Reduced-motion-safe by default.
+---
+
+You will produce a motion spec for the surface described in `$ARGUMENTS`. The argument may be a component name, screen description, or design link.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- A surface (e.g., "landing hero", "modal open", "route transition", "checkout success state").
+- Optionally: trigger (e.g., "on scroll into view", "on submit"), platform (web / mobile / native), brand voice (Toss-style / playful / minimal).
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Classify the moment** into one of: micro-interaction, marketing motion, app loading, choreography, state transition. The category determines the rules — see [`skills/motion-designer/PLAYBOOK.md`](../skills/motion-designer/PLAYBOOK.md) step 1.
+
+2. **Apply the [motion-designer playbook](../skills/motion-designer/PLAYBOOK.md)**:
+   - Pick duration tier → easing → tool → properties.
+   - Choreograph if multi-element.
+   - Specify reduced-motion fallback.
+   - Verify performance budget.
+
+3. **Output** using the structure in PLAYBOOK.md step 10:
+
+```markdown
+# Motion spec: <surface>
+
+> Surface: <...>
+> Intent: <one sentence>
+> Trigger: <...>
+> Tool: <CSS | Framer Motion | GSAP | Lottie | Rive | react-spring>
+
+## Tokens used
+## Sequence
+## Timing diagram
+## Reduced motion
+## Performance budget
+## Code stub
+## Don't
+```
+
+## Done when
+
+- Surface, intent, trigger, and tool stated.
+- Duration tier and easing tokenized (no raw values in body).
+- Animated properties limited to `opacity` / `transform` / `filter`.
+- Stagger ≤ 80ms; total entrance ≤ 800ms.
+- `prefers-reduced-motion` fallback specified for every element.
+- Performance budget (bundle delta, animation count, LCP impact) stated.
+- Code stub a developer can paste in.
+- "Don't" section catches 2–3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/palette-from-brand.md

@@ -0,0 +1,50 @@
+---
+description: Generate a full color palette (ramps + semantic aliases + dark mode + contrast matrix) from a brand input (hex, product category, or mood).
+---
+
+You will produce a full color palette using the [`color-palette` skill playbook](../skills/color-palette/PLAYBOOK.md).
+
+## Input
+
+Parse `$ARGUMENTS`. The user will provide one of:
+- A hex (e.g., `#7C3AED`)
+- A product category (e.g., `fintech`, `e-commerce`, `health-tech`)
+- A mood word (e.g., `playful`, `editorial`, `brutalist`)
+- Multiple of these, comma-separated
+
+If the input is ambiguous or missing, ask one clarifying question before proceeding.
+
+## Steps
+
+1. Determine the seed:
+   - If hex: it's the primary.
+   - If category: pull a starter from [`knowledge/colors/palettes-by-product-type.md`](../knowledge/colors/palettes-by-product-type.md).
+   - If mood: pull primary/accent from [`knowledge/patterns/styles-catalog.md`](../knowledge/patterns/styles-catalog.md).
+
+2. Apply the [`color-palette` playbook](../skills/color-palette/PLAYBOOK.md) end-to-end:
+   - OKLCH ramp generation
+   - Semantic anchors (default, hover, active, subtle, on-color)
+   - Accent + neutrals
+   - WCAG validation (matrix)
+   - Dark mode (recomputed, not inverted)
+
+3. Output using [`skills/color-palette/TEMPLATE.md`](../skills/color-palette/TEMPLATE.md):
+   - Reasoning paragraph
+   - Token table (light + dark)
+   - Code blocks for the requested framework (default: Tailwind v4 + shadcn-ui CSS vars + Style Dictionary JSON)
+   - Contrast matrix
+   - Use guidance
+
+## Default assumptions if not specified
+
+- Both light and dark mode.
+- Tailwind v4 + shadcn-ui CSS vars + Style Dictionary JSON output.
+- WCAG AA target (not AAA).
+- 11-step ramps (`50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950`).
+
+## Done when
+
+- Every UI-relevant pair has a contrast number.
+- Dark mode is genuinely recomputed.
+- Code blocks for at least Tailwind + shadcn vars are paste-ready.
+- Use guidance addresses primary vs accent vs neutral selection.

package/commands/print.md

@@ -0,0 +1,49 @@
+---
+description: Spec a print piece — business card, brochure, poster, packaging, or stationery system. CMYK + Pantone, bleed, finish, file delivery; Korean print conventions baked in.
+---
+
+You will produce a print-ready spec for the piece described in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- A piece type ("business card", "tri-fold brochure", "subway poster", "cosmetics carton").
+- Optionally: brand, audience (Korean / international), tier (basic / premium), quantity, special requirements.
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Pick the right piece category** (stationery / brochures / signage / packaging) and consult the matching knowledge file.
+
+2. **Apply the [print-designer playbook](../skills/print-designer/PLAYBOOK.md)**:
+   - Spec dimensions + bleed + safe area.
+   - Pick paper / material.
+   - Pick color (CMYK + Pantone).
+   - Pick finish + special effects.
+   - Spec typography.
+   - Apply regulatory content if required (food / cosmetics / supplements).
+   - Spec file delivery format (PDF/X-1a + outlined fonts + embedded images + ICC).
+
+3. **Apply Korean print conventions** if KR audience:
+   - 명함 90×50 (not 85×55).
+   - Pretendard typography defaults.
+   - KFDA / KATS regulatory content.
+   - 분리배출 표시 recycling marks for packaging.
+
+4. **Output** using the structure in PLAYBOOK.md step 9.
+
+## Done when
+
+- Dimensions + bleed (3mm min) + safe area.
+- Paper / material + finish + special effects.
+- Color (CMYK + Pantone explicit).
+- Typography (fonts, sizes, weights per role).
+- Layout (per panel for multi-panel pieces).
+- Regulatory checklist if applicable.
+- Cost estimate.
+- File delivery format (PDF/X-1a + outlined fonts).
+- Pre-press checklist.
+- Press proof step for brand-critical color.
+- "Don't" section catches 2-3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/slide-deck.md

@@ -0,0 +1,46 @@
+---
+description: Generate a slide deck outline from a brief. Picks archetype (talk / pitch / reading), drafts message-led slide titles, specifies visuals per slide, applies brand. Korean-aware.
+---
+
+Apply the [`slide-deck-author` skill](../skills/slide-deck-author/PLAYBOOK.md) to the brief in `$ARGUMENTS`.
+
+## Input
+
+`$ARGUMENTS` should describe:
+- Topic + thesis (one-line takeaway)
+- Type — talk / pitch / reading (warn if reading)
+- Length (minutes for talk; slide count for pitch)
+- Audience
+- Brand (color / font / logo / voice)
+- Locale (Korean / English / both)
+
+## Steps
+
+1. Parse brief.
+2. Pick archetype. If "reading deck": warn that documents render better, then proceed.
+3. Apply [`skills/slide-deck-author/PLAYBOOK.md`](../skills/slide-deck-author/PLAYBOOK.md):
+   - Outline slide-by-slide with message-led titles.
+   - Pick one visual per slide.
+   - Apply brand.
+   - Add speaker notes for live decks.
+4. Output: outline markdown + (optional) render-ready format.
+5. Run verification phase.
+
+## Examples
+
+**Brief**: "20-min conference talk on design tokens for designers. Brand color teal."
+→ 18-slide talk deck. Hook → 3 arguments → conclusion. Diagrams + before/after charts. Speaker notes for each slide.
+
+**Brief**: "Seed pitch deck for a Korean fintech app. 12 slides max."
+→ Sequoia-style pitch: hero / problem / solution / why-now / product / traction / business model / competition / team / ask. Korean copy. Toss-style aesthetic.
+
+**Brief**: "Reading deck for an internal architecture review."
+→ Warning that this should be a doc. If user insists: medium-density deck with each slide self-contained.
+
+## Done when
+
+- Outline markdown delivered with per-slide titles + visuals.
+- Each title is a **message**, not a topic.
+- One visual concept per slide.
+- Brand applied.
+- Verification phase from `slide-deck-author` passes.

package/commands/spatial.md

@@ -0,0 +1,47 @@
+---
+description: Spec a spatial / AR / VR / MR experience. Platform, anchoring, locomotion, UI elements, comfort, accessibility; Korean Galaxy XR + KR market context.
+---
+
+You will produce a spatial design spec for the experience described in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- An experience (e.g., "Vision Pro productivity app", "Quest VR training", "iOS ARKit product viewer", "HoloLens medical training", "WebXR exhibit").
+- Optionally: mode (VR / AR / MR / WebXR), platform, use case, audience, session length.
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Pick mode + platform** to determine which knowledge files apply (VR vs AR; Vision Pro vs Quest vs HoloLens vs mobile).
+
+2. **Apply the [spatial-designer playbook](../skills/spatial-designer/PLAYBOOK.md)**:
+   - Spatial geometry (coordinate system, height, comfort distance, FOV).
+   - Anchoring per UI element (world / wrist / hand / head / object).
+   - Locomotion if VR (teleport / smooth / hybrid + comfort options).
+   - Input methods + accessibility alternatives (hand / controller / gaze / voice).
+   - UI elements with sizing, states, audio.
+   - Comfort options (locomotion, vignette, motion, flashing).
+   - Accessibility across vision / hearing / motor / cognitive.
+   - Onboarding.
+   - Korean / regional considerations.
+   - Performance budget.
+
+3. **Output** using the structure in PLAYBOOK.md step 12.
+
+## Done when
+
+- Mode + platform + use case + audience explicit.
+- Spatial geometry specified.
+- Anchoring per UI element documented.
+- Locomotion options if VR (with comfort defaults).
+- Input methods + alternatives.
+- UI elements with sizing + states.
+- Comfort options addressed.
+- Accessibility plan covering vision / hearing / motor / cognitive / photosensitive / mobility.
+- Onboarding planned.
+- Korean / regional considerations if applicable.
+- Performance budget stated.
+- "Don't" catches 2-3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/stability-review.md

@@ -0,0 +1,74 @@
+---
+description: Run the quarterly stability review report. Surfaces files due for promotion or re-review.
+---
+
+You are running the quarterly stability review for the design-ai knowledge corpus.
+
+## Step 1 — Generate the report
+
+Run:
+
+```bash
+python3 tools/audit/stability-review.py --output docs/STABILITY-REVIEW.md
+```
+
+This produces `docs/STABILITY-REVIEW.md` with:
+- Summary by stability level (stable / beta / experimental / deprecated).
+- Promotion candidates (experimental → stable after 6mo; beta → stable after 3mo).
+- Stable files due for re-review (≥ 12 months old).
+- Deprecated files awaiting removal in next major.
+- Files missing the `stability` metadata.
+
+## Step 2 — Read the report and summarize for the user
+
+Read the generated `docs/STABILITY-REVIEW.md` and summarize:
+
+```
+Stability review summary:
+- N files at stable, M at beta, K at experimental, J at deprecated.
+- Promotion candidates: X experimental → stable, Y beta → stable.
+- Re-review needed: Z stable files > 12 months old.
+- Action items: ...
+```
+
+## Step 3 — Suggest the next bulk operation (don't run it without confirmation)
+
+If there are promotion candidates, offer to run:
+
+```bash
+python3 tools/migrations/promote-stability.py --from <level> --to stable <files...>
+```
+
+If there are stale stable files, offer to run:
+
+```bash
+python3 tools/migrations/bump-last-updated.py <files...>
+```
+
+Both tools support `--dry-run`. Always dry-run first; ask the user to confirm before applying.
+
+## Step 4 — Document the outcome
+
+After the user confirms changes, suggest a CHANGELOG entry:
+
+```markdown
+### Stability review (Q<N> <YYYY>)
+- Promoted to stable: <list>
+- Reviewed + bumped: N files
+```
+
+## Reference
+
+- Full ritual documentation: [`docs/CONTRIBUTING.md`](../docs/CONTRIBUTING.md) "Quarterly stability review"
+- Tools:
+  - `tools/audit/stability-review.py`
+  - `tools/migrations/promote-stability.py`
+  - `tools/migrations/bump-last-updated.py`
+
+## Verification phase (run before declaring done)
+
+- [ ] Did I run `stability-review.py` and read the output?
+- [ ] Did I summarize the report for the user (counts + action items)?
+- [ ] Did I dry-run any bulk operation before applying?
+- [ ] Did I get user confirmation before running mutation commands?
+- [ ] Did I propose a CHANGELOG entry for the changes?

package/commands/video.md

@@ -0,0 +1,42 @@
+---
+description: Spec video for marketing, social, or in-product use. Picks length, format, aspect ratio, codec, captions, voiceover. Korean conventions and ad disclosure included.
+---
+
+You will produce a video spec for the surface described in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- A surface (e.g., "landing-page hero loop", "product demo", "Reels campaign", "onboarding video", "TVCM 30s spot").
+- Optionally: platform, length, audience (Korean / international), brand voice, budget.
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Classify the video** into one of: hero loop / brand film / product demo / onboarding / help / short-form / ad spot. The category determines rules.
+
+2. **Apply the [video-designer playbook](../skills/video-designer/PLAYBOOK.md)**:
+   - Spec technical format (resolution, fps, codec, audio, aspect).
+   - Pick length per surface category.
+   - Outline script structure (hook / body / CTA).
+   - Spec captions (language tracks + style + format).
+   - Spec voiceover if applicable (language, tone, honorific level).
+   - Spec music (source + loudness).
+   - Apply Korean ad disclosure + KFDA compliance if applicable.
+   - File delivery format (multi-codec, poster, HLS for streaming).
+
+3. **Output** using the structure in PLAYBOOK.md step 10.
+
+## Done when
+
+- Surface, platform, audience, length explicit.
+- Technical specs (resolution, fps, codec, audio, captions) stated.
+- Script structure with timing.
+- Captions language + format specified.
+- Voiceover or audio strategy explicit.
+- Korean compliance (ad disclosure, KFDA) addressed if applicable.
+- File delivery format (poster, multi-codec, performance) specified.
+- Reduced-motion / slow-connection fallback for autoplay.
+- "Don't" section catches 2-3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/website-improvement.md

@@ -0,0 +1,77 @@
+---
+description: Plan a website improvement project with Site Profile, audit checklist, MCP readiness, refactor tasks, prompts, and handoff report.
+---
+
+You will produce a Website Improvement plan for the site described in `$ARGUMENTS`. The target website source code does not live in design-ai; implementation happens later in the target website repository.
+
+## Steps
+
+1. Read the workflow source:
+   - `skills/website-improvement/PLAYBOOK.md`
+   - `skills/website-improvement/TEMPLATE.md`
+   - `knowledge/PRINCIPLES.md`
+   - `knowledge/patterns/ux-guidelines.md`
+   - `knowledge/a11y/contrast.md`
+   - `knowledge/a11y/keyboard-and-focus.md`
+   - `knowledge/layout/spacing-and-grid.md`
+   - `knowledge/patterns/report-design.md`
+   - `docs/MCP-INTEGRATION.md`
+
+2. Build a Site Profile:
+   - site name
+   - live URL
+   - repo URL or local path
+   - priority pages
+   - Figma URL
+   - brand/design notes
+   - deploy provider
+   - Sentry project
+   - CMS and database
+   - user flows
+   - desktop/tablet/mobile viewports
+
+3. Create an Audit Checklist across:
+   - Visual Design
+   - UX Flow
+   - Responsive QA
+   - Accessibility
+   - Performance
+   - SEO
+   - Technical Quality
+   - Runtime Issues
+   - Content Quality
+
+4. Create an MCP Readiness Matrix. Use only `required`, `optional`, `unused`, or `unavailable`. Do not claim live MCP access unless the current agent actually has it.
+
+5. Convert findings into Refactor Tasks. Each task must include:
+   - problem
+   - evidence
+   - impact
+   - effort
+   - priority
+   - pages
+   - recommended MCP
+   - Codex prompt
+   - verification
+   - risks
+
+6. Generate prompt templates for:
+   - Codex repo intake
+   - Codex implementation
+   - Codex visual QA
+   - Codex deployment verification
+   - Claude design review
+   - Claude competitor research
+   - Claude copy/UX critique
+   - final handoff report
+
+7. Draft the Handoff Report with target site information, diagnostic summary, priority recommendations, executed work placeholders, verification placeholders, remaining risks, and next actions.
+
+## Output
+
+Follow `skills/website-improvement/TEMPLATE.md`. Keep the report dense and operational. Cite checked knowledge files when making design, accessibility, UX, or report-structure recommendations.
+
+## Done when
+
+- The artifact can be checked with `design-ai check output.md --route website-improvement --strict`.
+- The MVP boundary is explicit: no automatic crawling, external writes, target repo mutation, embeddings, fine-tuning, or backend sync.