monomind 2.7.9 → 2.7.11

package/packages/@monomind/cli/.claude/skills/monodesign/delight.md

@@ -1,47 +0,0 @@
----
-name: monodesign-delight
-description: Add moments of delight, whimsy, and personality to interfaces — micro-interactions, easter eggs, playful copy, unexpected moments that make users smile without sacrificing usability.
-type: design-sub-command
-argument-hint: "[target component, empty state, interaction, or whole product]"
-user-invocable: true
----
-
-# Monodesign: Delight
-
-Add moments of delight, whimsy, and personality. Read `reference/delight.md` from the monodesign skill directory for the full protocol.
-
-## Philosophy
-
-Delight is not decoration. It's the feeling a user gets when the product treats them as a human, not a task-completer. The best delight is:
-- **Discovered, not announced** — it rewards exploration, it doesn't interrupt
-- **Appropriate to context** — a playful empty state is right; a playful error message on a failed payment is wrong
-- **Consistent with brand personality** — delight that contradicts the brand voice creates whiplash
-
-## Where Delight Lives
-
-**Empty states**
-The most underdesigned surface in almost every product. When a user has no data, they're often new and uncertain. An empty state that's warm, encouraging, and occasionally charming turns uncertainty into curiosity.
-
-**Micro-interactions**
-The moments that feel physical: a button that compresses on press, a toggle that snaps, a checkbox that checks with a tiny satisfying arc, a completion animation that celebrates without being overwrought.
-
-**Copy**
-Delight isn't always visual. An error message that says "Hmm, that didn't work — here's what we know:" treats the user as a collaborator. Copy that has a voice (specific to this product, not generic SaaS) is delightful in itself.
-
-**Easter eggs**
-Hidden interactions that reward the curious. The konami code that does something silly. A hover state that's unexpectedly specific. A tooltip that breaks the fourth wall once.
-
-**Loading states**
-Instead of a spinning circle, something that's interesting to watch. A progress animation that tells you something about what the product is doing.
-
-## Delight Hierarchy
-
-Rate each idea against:
-1. **Does it interrupt the user's task?** If yes, cut it. Delight never gets in the way.
-2. **Is it consistent with the brand personality?** A product that's "expert, decisive, editorial" shouldn't have cartoon characters.
-3. **Does it degrade gracefully?** The primary function must work even if the delightful layer fails.
-4. **Will it get old?** Animations that play every time something happens become annoying. Use sparingly.
-
-## Implementation
-
-Read `reference/delight.md` for specific delight patterns by component type (empty states, interactions, copy formulas, animation recipes).

package/packages/@monomind/cli/.claude/skills/monodesign/distill.md

@@ -1,56 +0,0 @@
----
-name: monodesign-distill
-description: Simplify an over-designed, cluttered, or complexity-burdened interface — remove what doesn't earn its place, reveal the essential structure underneath.
-type: design-sub-command
-argument-hint: "[target page, flow, or component]"
-user-invocable: true
----
-
-# Monodesign: Distill
-
-Simplify an over-designed or cluttered interface. Read `reference/distill.md` from the monodesign skill directory for the full protocol.
-
-## Philosophy
-
-Every element on a page is a claim on the user's attention. When too many claims compete equally, the user's attention costs rise and comprehension falls. Distill removes the claims that can't justify their cost.
-
-## Assess the Clutter
-
-Walk through the interface and identify:
-
-**Structural complexity**
-- How many distinct visual layers exist? (More than 3 is usually too many)
-- How many columns? (Sometimes 1 column is the right answer)
-- Are there containers-within-containers? (Nested cards are always wrong)
-- Is the Z-axis used purposefully or as a decoration?
-
-**Information redundancy**
-- Is the same information shown twice? (Heading + tooltip + label that all say the same thing)
-- Are there labels that label things that are already obvious from context?
-- Are there intros that restate the page title?
-
-**Visual noise**
-- Decorative dividers between every section when whitespace would suffice
-- Icon + text where one alone would communicate equally well
-- Background patterns, textures, or gradients that add nothing
-
-**Navigation complexity**
-- Are there paths that lead nowhere useful?
-- Are there settings no one changes?
-- Are there features that serve < 5% of users in the primary navigation?
-
-## Distillation Protocol
-
-1. **List every element** on the target surface (visual inventory)
-2. **For each element, ask**: if this were removed, would a first-time user notice something missing? If no: remove it
-3. **Consolidate redundant information** into one canonical location
-4. **Increase whitespace** where elements were removed — don't fill the vacuum with something else
-5. **Verify the essential path** still works and is faster than before
-
-## Output
-
-A version of the interface that is measurably simpler:
-- Fewer distinct visual elements on screen at once
-- Clearer visual hierarchy (the important thing is visually louder than the less-important thing)
-- Faster to scan for a first-time user
-- No functionality removed from the primary user path

package/packages/@monomind/cli/.claude/skills/monodesign/document.md

@@ -1,83 +0,0 @@
----
-name: monodesign-document
-description: Create or update DESIGN.md — extract and codify the design system from the codebase into a portable, AI-readable design reference that anchors all future monodesign work.
-type: design-sub-command
-argument-hint: "[project path]"
-user-invocable: true
----
-
-# Monodesign: Document
-
-Create or update `DESIGN.md` — the design system reference for this project. Every `/monodesign` sub-command uses DESIGN.md to make on-brand decisions without asking the same questions repeatedly.
-
-DESIGN.md is the portable export of the project's design system: colors, typography, spacing, components, and conventions — extracted from what's actually in the code, not invented.
-
-Read `reference/document.md` from the monodesign skill directory for the full protocol.
-
-## Discovery
-
-**Extract from codebase (monograph-first):**
-```
-# Preferred: monograph for design token discovery
-monograph_query({ query: "CSS custom properties variables tokens" })
-monograph_query({ query: "font-family font-face typography" })
-monograph_query({ query: "color theme palette" })
-```
-
-**Fallback (if monograph returns 0 results or DB not built):**
-```bash
-grep -r "^--" src/ --include="*.css" --include="*.scss" -h | sort -u
-grep -r "font-family\|@font-face\|@import.*font" src/ -h | sort -u
-grep -rE "#[0-9a-fA-F]{3,8}|oklch\(|rgb\(|hsl\(" src/ -h | sort -u | head -50
-```
-
-**Also read:**
-- `tailwind.config.js/ts` — theme configuration
-- `tokens.css`, `theme.css`, `variables.css`, or equivalent
-- A representative component to understand CSS conventions
-
-## DESIGN.md Structure
-
-```markdown
-# Design System
-
-## Brand Identity
-**Name**: [product name]
-**System**: [design system name, e.g. "Neo kinpaku system"]
-**Strategy**: [Restrained | Committed | Full palette | Drenched]
-**Theme**: [dark | light | both]
-
-## Colors (OKLCH)
-
-### Brand
-| Token | Value | Use |
-|---|---|---|
-| --color-brand | oklch(…) | Primary accent |
-| --color-brand-muted | oklch(…) | Secondary accent |
-
-### Surfaces
-[table]
-
-### Text
-[table]
-
-## Typography
-
-| Role | Font | Size | Weight | Line Height |
-|---|---|---|---|---|
-| Display | [family] | clamp(3rem, 5vw, 5rem) | 800 | 1.1 |
-| Heading 1 | … | … | … | … |
-| Body | … | 1rem | 400 | 1.6 |
-| Caption | … | 0.875rem | 400 | 1.4 |
-
-## Spacing Scale
-[4 / 8 / 12 / 16 / 24 / 32 / 48 / 64 / 96 / 128]
-
-## Components
-[Brief description of key shared components and their variants]
-
-## Conventions
-- File naming: [convention]
-- Token naming: [convention]  
-- Component import style: [named/default/barrel]
-```

package/packages/@monomind/cli/.claude/skills/monodesign/extract.md

@@ -1,74 +0,0 @@
----
-name: monodesign-extract
-description: Extract an implicit design system from an existing codebase — discover tokens, components, patterns, and conventions already present, then codify them into a formal system.
-type: design-sub-command
-argument-hint: "[target codebase path or project]"
-user-invocable: true
----
-
-# Monodesign: Extract
-
-Extract a design system from an existing codebase. Read `reference/extract.md` and `reference/token-architecture.md` from the monodesign skill directory for the full protocol.
-
-## Philosophy
-
-Every codebase with more than a few pages has an implicit design system — inconsistencies, but also patterns that have emerged over time. Extract makes the implicit explicit, without inventing a new system on top of what exists.
-
-## Discovery Phase
-
-**Color inventory**
-- Collect all color values used in the codebase (use `monograph_query({ query: "color rgb hsl oklch" })` first; fall back to grep for `#`, `rgb`, `hsl`, `oklch` if monograph returns 0 results)
-- Group by apparent purpose (backgrounds, text, accents, borders, shadows)
-- Identify the brand anchor color(s)
-- Spot inconsistencies (5 slightly different grays)
-
-**Typography inventory**
-- Collect all font-family, font-size, font-weight, line-height, letter-spacing values
-- Map to semantic roles (heading-xl, heading-lg, body, caption, etc.)
-- Identify the type scale (if any)
-
-**Spacing inventory**
-- Collect all padding, margin, gap values
-- Identify if a consistent scale exists (4/8/16/24/32/48...)
-- Spot outliers
-
-**Component inventory**
-- List all recurring UI patterns (buttons, inputs, cards, badges, modals)
-- Note variants (primary/secondary/ghost buttons, etc.)
-- Identify inconsistent implementations of the same component
-
-## Codification
-
-**Token architecture** (CSS custom properties):
-```css
-:root {
-  /* Colors */
-  --color-brand-[scale]: oklch(…);
-  --color-surface-[level]: oklch(…);
-  --color-ink-[weight]: oklch(…);
-  
-  /* Type scale */
-  --text-[size]: [value];
-  --font-[role]: [family];
-  
-  /* Spacing scale */
-  --space-[size]: [rem];
-  
-  /* Radius */
-  --radius-[size]: [rem];
-}
-```
-
-**Component documentation**
-For each identified component: props, variants, states, example usage.
-
-## Output: DESIGN.md
-
-Write a `DESIGN.md` at the project root capturing:
-- Brand colors with OKLCH values
-- Type scale and font families
-- Spacing scale
-- Key components with their states
-- Design conventions (rounded vs. sharp, dense vs. airy, etc.)
-
-This becomes the anchor for all future `/monodesign` work on this project.

package/packages/@monomind/cli/.claude/skills/monodesign/harden.md

@@ -1,65 +0,0 @@
----
-name: monodesign-harden
-description: Fix accessibility violations, keyboard navigation gaps, semantic HTML issues, ARIA problems, and contrast failures — bring the interface to WCAG AA compliance.
-type: design-sub-command
-argument-hint: "[target page or component]"
-user-invocable: true
----
-
-# Monodesign: Harden
-
-Fix accessibility and robustness issues. Read `reference/harden.md` from the monodesign skill directory for the full protocol.
-
-## Accessibility Targets
-
-**WCAG AA** is the floor:
-- Body text: ≥4.5:1 contrast ratio
-- Large text (≥18px or bold ≥14px): ≥3:1
-- Interactive element focus indicators: ≥3:1 against adjacent colors
-- No information conveyed by color alone
-
-**Keyboard navigation**
-- Every interactive element reachable by Tab in logical order
-- Visible focus ring on every focused element (never `outline: none` without a replacement)
-- No keyboard traps
-- Escape closes modals and dropdowns
-- Arrow keys navigate within a group (menu items, radio buttons, tabs)
-
-**Semantic HTML**
-- Heading hierarchy is sequential (h1 → h2 → h3, no skipping)
-- Landmark roles present (main, nav, aside, footer)
-- Interactive elements use native elements (button, a, input) not div
-- Forms have labels associated with inputs (via for/id or wrapping label)
-
-**ARIA**
-- Used only when native semantics can't convey the role
-- `aria-label` on icon-only buttons
-- `aria-expanded`, `aria-controls` on toggle buttons
-- `aria-live` on dynamic content that updates without page reload
-- `role="status"` or `role="alert"` on notification areas
-
-**Images**
-- Decorative images: `alt=""`
-- Informative images: alt describes the information (not "image of...")
-- Icon images: alt is the icon's semantic meaning
-
-## Hardening Checklist
-
-```
-[ ] Run automated check: `npx axe <url>` or equivalent
-[ ] Tab through entire page — every interactive element reachable
-[ ] Check all headings form a logical hierarchy
-[ ] Verify all contrast ratios pass
-[ ] Test all interactive elements with keyboard only
-[ ] Verify screen reader announces dynamic content
-[ ] Check all forms have properly associated labels
-[ ] Test at 200% zoom — nothing overlaps or disappears
-[ ] Verify reduced motion preference is respected
-```
-
-## Never
-
-- `outline: none` or `outline: 0` without a replacement focus indicator
-- `tabindex="-1"` on focusable elements without a keyboard alternative
-- Color as the only differentiator between states
-- ARIA roles that contradict the HTML semantics (role="button" on an anchor that navigates)

package/packages/@monomind/cli/.claude/skills/monodesign/init.md

@@ -1,30 +0,0 @@
----
-name: monodesign-init
-description: Set up a project for monodesign — one codebase crawl plus a short interview produces PRODUCT.md (strategic context), optionally DESIGN.md (visual system), and pre-configures live mode. The required first step that anchors all other monodesign commands.
-type: design-sub-command
-argument-hint: "[project path or description]"
-user-invocable: true
----
-
-# Monodesign: Init
-
-Set up a project for monodesign. Read `reference/init.md` from the monodesign skill directory for the full flow — it is the authoritative protocol. (`/monodesign teach` is the historical alias; it behaves identically.)
-
-## What init produces
-
-- **PRODUCT.md** (strategic): register, target users, product purpose, brand personality, anti-references, strategic design principles. Answers "who/what/why".
-- **DESIGN.md** (visual, offered via `/monodesign document`): visual theme, color palette, typography, components, layout. Answers "how it looks".
-- **`.monodesign/live/config.json`**: pre-configured live mode so `/monodesign live` boots straight into variant mode.
-
-## Flow summary (the reference is authoritative)
-
-1. **Load current state**: check for existing PRODUCT.md / DESIGN.md (project root, `.agents/context/`, `docs/`). Never silently overwrite — confirm which file to refresh. A legacy `.monodesign.md` is auto-renamed to PRODUCT.md by the loader.
-2. **Explore the codebase**: one thorough crawl — README/docs, package.json and framework detection, existing components, brand assets, design tokens. Form a register hypothesis (brand vs product vs both) and a platform hypothesis (`web` / `ios` / `android` / `adaptive`).
-3. **Interview**: ask strategic questions to fill PRODUCT.md — register and platform confirmation, users, purpose, positioning, brand personality, anti-references, accessibility needs (plus conversion & proof for the brand register). Never synthesize PRODUCT.md from the task prompt alone; the user confirms before you write.
-4. **Write PRODUCT.md** with only what the user confirmed.
-5. **Offer DESIGN.md** via `/monodesign document` — scan mode when code exists, seed mode for empty projects.
-6. **Pre-configure live mode** when the project has HTML entries and a dev server.
-
-## Blocker behavior
-
-If init was invoked as a setup blocker by another command (e.g. `/monodesign craft` with no PRODUCT.md), complete init, then resume the original command with the fresh context.

package/packages/@monomind/cli/.claude/skills/monodesign/layout.md

@@ -1,36 +0,0 @@
----
-name: monodesign-layout
-description: Fix the structure, not the surface — diagnose a layout's actual problem (monotone spacing, weak hierarchy, identical card grids) and restructure spacing, grids, and composition for the project's register.
-type: design-sub-command
-argument-hint: "[target file, route, or component]"
-user-invocable: true
----
-
-# Monodesign: Layout
-
-Space is the most underused design tool. Find the layout's actual problem and fix the structure, not the surface. Read `reference/layout.md` from the monodesign skill directory for the full protocol.
-
-## Register-aware structure
-
-- **Brand**: asymmetric compositions, fluid spacing with `clamp()`, intentional grid-breaking for emphasis. Rhythm through contrast — tight groupings paired with generous separations.
-- **Product**: predictable grids, consistent densities, familiar navigation patterns. Responsive behavior is structural (collapse sidebar, responsive table), not fluid typography. Consistency IS an affordance.
-- **Native** (`ios` / `android` / `adaptive`): follow the Layout section of `reference/ios.md` / `reference/android.md` — platform navigation, insets, and touch targets, never web CSS tooling.
-
-## Two isolated assessments (required)
-
-Spawn two parallel sub-agents (isolation is the point — neither sees the other's output):
-
-1. **Layout assessment**: works through the full "Assess Current Layout" checklist from the reference, returning per-item findings that cite file, selector, or value.
-2. **Mechanical pre-scan**: runs the bundled detector scoped to layout:
-
-   ```bash
-   node .claude/skills/monodesign/scripts/detect.mjs --json --scope layout [target files or dirs]
-   ```
-
-   When the project documents a spacing scale, also grep arbitrary Tailwind spacing (`gap-[`, `p-[`, `m-[`, `z-[`) and judge those hits against it.
-
-If no sub-agent tool is available, run both yourself — assessment first, pre-scan second, so deterministic findings can't anchor the visual judgment.
-
-## Then
-
-Synthesize both assessments, propose the structural fix (spacing rhythm, grid restructure, hierarchy weight), apply it, and re-run the detector to confirm the layout-scope findings are resolved.

package/packages/@monomind/cli/.claude/skills/monodesign/live.md

@@ -1,34 +0,0 @@
----
-name: monodesign-live
-description: Interactive live variant mode — select elements in the browser, pick a design action, and get AI-generated HTML+CSS variants hot-swapped via the dev server's HMR. Iterate until the live result matches the design intent.
-type: design-sub-command
-argument-hint: "[target URL, route, or app path]"
-user-invocable: true
----
-
-# Monodesign: Live
-
-Interactive live variant mode. This is a fully functional, script-driven flow — not a manual screenshot loop. Read `reference/live.md` from the monodesign skill directory for the full protocol and follow its contract exactly (boot, poll, generate, steer, accept/discard, exit).
-
-## Prerequisites
-
-- A running dev server with hot module replacement (Vite, Next.js, Bun, etc.), OR a static HTML file open in the browser.
-- Node available on PATH (the flow runs the bundled live helper scripts).
-- If `.monodesign/live/config.json` exists (written by `/monodesign init`), live boots straight into variant mode with no first-time setup detour.
-
-## How it works (summary — the reference is authoritative)
-
-1. **Boot**: run `live.mjs` (with `--target <path>` when the request names a specific file, route, or monorepo app). It starts the live helper server and injects the in-page toolbar.
-2. **Open the app URL** that serves the page (the app's own dev-server URL — never the helper's `serverPort`).
-3. **Poll loop**: long-poll with `live-poll.mjs` (default long timeout). The user selects elements in the browser and picks a design action from the toolbar.
-4. **On `generate`**: read the screenshot if present, load the action's reference file, plan three distinct directions, write all variants in one edit, reply done, poll again.
-5. **On `steer`**: handle the user's free-text instruction, reply, poll again.
-6. **On `accept` / `discard`**: the accepted variant is committed to source (carbonize accepts have a cleanup step via `live-complete.mjs`); discards roll back.
-7. **If interrupted**: run `live-status.mjs` or `live-resume.mjs` — the durable journal replays unacknowledged work.
-8. **On `exit`**: run the cleanup steps at the bottom of the reference.
-
-## Guidelines
-
-- Never pass a short poll timeout; restart the poll immediately after every event.
-- Variants are written as real source edits hot-swapped by HMR — deliver code that can be committed, not browser-only overrides.
-- Manual in-browser edits are captured and can be committed or discarded via `live-commit-manual-edits.mjs` / `live-discard-manual-edits.mjs`.

package/packages/@monomind/cli/.claude/skills/monodesign/onboard.md

@@ -1,50 +0,0 @@
----
-name: monodesign-onboard
-description: Design or improve user onboarding — first-run experiences, empty states, progressive disclosure, setup wizards, and the "aha moment" path for new users.
-type: design-sub-command
-argument-hint: "[target product or feature to onboard]"
-user-invocable: true
----
-
-# Monodesign: Onboard
-
-Design or improve user onboarding. Read `reference/onboard.md` from the monodesign skill directory for the full protocol.
-
-## Onboarding Philosophy
-
-The goal of onboarding is not to explain the product. It's to get the user to their first moment of value as fast as possible. Everything that doesn't serve that goal is a liability.
-
-## The Aha Moment Map
-
-Before designing anything, identify:
-1. **What is the first moment of genuine value for a new user?** (Not "they understand the product" — what specific thing makes them say "oh, this is useful")
-2. **What is the shortest path to that moment?** (Every step that isn't required is a step where the user can drop off)
-3. **What does the user need to know before they can get there?** (Only these things — nothing more)
-
-## Onboarding Patterns
-
-**Empty state onboarding**
-The most overlooked opportunity. When a user first arrives at a feature with no data, the empty state is their first experience of that feature. It should:
-- Describe what will appear here (not be blank)
-- Show a CTA to add the first item
-- Optionally show a preview of what it will look like when populated
-
-**Progressive disclosure onboarding**
-Start with the minimal useful version of the product. Reveal additional features only when the user's behavior signals readiness (they've used the basic feature N times, or they've hit a limitation).
-
-**Contextual tooltips**
-Not a tour. Tooltips that appear at the right moment (user hovers a new feature, user completes an action) and disappear when dismissed. Never a forced 10-step tour.
-
-**Setup wizard**
-When the product genuinely requires configuration before it's useful (API keys, workspace settings, integrations), a wizard is appropriate. Keep it short: 3 steps max, each with a clear benefit statement ("After this, you can...").
-
-## Copy Principles for Onboarding
-
-- Frame every step as a benefit: "Connect your calendar to automatically block focus time" not "Calendar integration step 2 of 3"
-- Progress indicators: show how far they've come, not how far they have to go
-- Skip options: always provide a way to skip or come back later
-- No dead ends: every empty state has an action, every error has a recovery path
-
-## Output
-
-Design decisions + code for the specific onboarding surface: empty states, tooltip content, wizard steps, or first-run flow — with copy, layout, and interaction states.

package/packages/@monomind/cli/.claude/skills/monodesign/optimize.md

@@ -1,64 +0,0 @@
----
-name: monodesign-optimize
-description: Improve frontend performance — animation smoothness, bundle size, rendering, image optimization, and Core Web Vitals — without sacrificing design quality.
-type: design-sub-command
-argument-hint: "[target page or component]"
-user-invocable: true
----
-
-# Monodesign: Optimize
-
-Improve frontend performance. Read `reference/optimize.md` from the monodesign skill directory for the full protocol.
-
-## Performance Target: Core Web Vitals
-
-- **LCP** (Largest Contentful Paint): ≤2.5s
-- **INP** (Interaction to Next Paint): ≤200ms
-- **CLS** (Cumulative Layout Shift): ≤0.1
-
-## Common Design-Layer Performance Issues
-
-**Animation performance**
-- Animating layout properties (`width`, `height`, `padding`, `margin`, `top`, `left`) causes layout recalculation on every frame — replace with `transform` and `opacity` only
-- Unbounded blur: `blur(20px)` on many elements is expensive — test and cap
-- `will-change: transform` tells the browser to promote to its own layer — use sparingly (memory cost)
-- Too many simultaneous animations — stagger rather than launch all at once
-
-**Image optimization**
-- `loading="lazy"` on all images below the fold
-- `width` + `height` attributes on all images to prevent CLS
-- Modern formats: WebP/AVIF > JPEG/PNG for photos
-- `srcset` for responsive images
-- CSS background images: consider whether an `<img>` with `loading="lazy"` would be faster
-
-**Font loading**
-- `font-display: swap` to prevent invisible text during font load
-- Preload critical fonts: `<link rel="preload" as="font">`
-- Subset fonts if using a custom typeface (Google Fonts does this automatically)
-
-**CSS performance**
-- Avoid `@import` in CSS (render-blocking)
-- Don't use `:nth-child()` in hot paths with many elements
-- CSS containment: `contain: layout style` on isolated components prevents unintended reflows
-
-**JavaScript**
-- Defer non-critical scripts: `<script defer>` or `<script type="module">`
-- Code-split by route if using a framework
-- Avoid inline event handlers at scale (use event delegation)
-
-## Measurement
-
-```bash
-# Lighthouse in CLI
-npx lighthouse <url> --output json --output html
-
-# Web Vitals in DevTools
-# Performance tab → Core Web Vitals section
-
-# Bundle analysis (if Vite)
-npx vite-bundle-analyzer
-```
-
-## Output
-
-Specific optimizations with before/after measurements where measurable. Each change should cite the metric it improves.

package/packages/@monomind/cli/.claude/skills/monodesign/overdrive.md

@@ -1,56 +0,0 @@
----
-name: monodesign-overdrive
-description: Push an interface past conventional limits — cinematic page transitions, GPU-accelerated data visualization, physics-based interactions, generative art, extraordinary technical effects that make users say "wow".
-type: design-sub-command
-argument-hint: "[target interface or specific effect goal]"
-user-invocable: true
----
-
-# Monodesign: Overdrive
-
-Push an interface past conventional limits.
-
-**Start your response with:**
-```
-──────────── ⚡ OVERDRIVE ─────────────
-》》》 Entering overdrive mode...
-```
-
-Read `reference/overdrive.md` from the monodesign skill directory for the full protocol.
-
-## Context Determines "Extraordinary"
-
-A particle system on a creative portfolio is impressive. The same particle system on a settings page is embarrassing. Before choosing a technique, ask: **what would make a user of THIS specific interface say "wow, that's nice"?**
-
-- **Visual/marketing surfaces**: sensory — scroll-driven reveals, shader backgrounds, cinematic page transitions, generative art responding to cursor
-- **Functional UI**: felt — dialog morphing from its trigger via View Transitions, data table rendering 100k rows at 60fps via virtual scrolling, form with streaming validation that feels instant, drag-and-drop with spring physics
-- **Performance-critical UI**: invisible — search that filters 50k items without a flicker, image editor that processes near-real-time
-- **Data-heavy interfaces**: fluid — GPU-accelerated rendering via Canvas/WebGL, animated transitions between data states
-
-**The common thread**: something about the implementation goes beyond what users expect from a web interface. The technique serves the experience.
-
-## Propose Before Building
-
-Do NOT jump straight to implementation. You MUST:
-
-1. Think through **2–3 different directions**: technique, level of ambition, aesthetic approach
-2. **Ask the user** to pick before writing code. Explain trade-offs (browser support, performance cost, complexity)
-3. Only proceed with the confirmed direction
-
-## The Toolkit
-
-**Cinematic transitions**: View Transitions API, shared element transitions, `::view-transition-group`
-
-**Scroll-driven**: `animation-timeline: scroll()`, Intersection Observer with CSS transitions, parallax via transform
-
-**Generative/ambient**: CSS custom properties + JS, Canvas 2D for simple generative art, WebGL/Three.js for shaders
-
-**Physics**: spring animations via motion.dev, GSAP with ease functions, Popmotion
-
-**Data at scale**: virtual scrolling (TanStack Virtual), Canvas/WebGL rendering, Web Workers for computation
-
-**GPU compositing**: `transform` + `opacity` only, `will-change` on animated layers, `contain: strict` for isolation
-
-## Iterate in Browser
-
-Technically ambitious effects almost never look right on the first try. Use browser automation to watch the effect play. Expect multiple rounds of refinement. The gap between "technically works" and "looks extraordinary" is closed through visual iteration, not code alone.