monomind 2.7.9 → 2.7.11

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

@@ -1,68 +0,0 @@
----
-name: monodesign-polish
-description: Perform a meticulous final pass to catch all the small details that separate good work from great work — design system alignment, interaction states, spacing precision, copy consistency, edge cases.
-type: design-sub-command
-argument-hint: "[target component, page, or feature]"
-user-invocable: true
----
-
-# Monodesign: Polish
-
-Perform a meticulous final pass. The difference between shipped and polished. Read `reference/polish.md` from the monodesign skill directory for the full protocol.
-
-## Design System Discovery (required first step)
-
-1. **Find the design system**: Look for documentation, component libraries, style guides, token definitions
-2. **Note the conventions**: spacing scale, color tokens, motion patterns, component API
-3. **Identify drift, then name the root cause**: classify each deviation as:
-   - **Missing token** — value should exist in the system but doesn't
-   - **One-off implementation** — shared component exists but wasn't used
-   - **Conceptual misalignment** — flow, IA, or hierarchy doesn't match neighboring features
-
-Polish **must** align the feature with the design system. If none exists, polish against visible codebase conventions.
-
-## Pre-Polish Assessment
-
-1. **Review completeness**: Is it functionally complete? Are there known issues to preserve (mark TODOs)?
-2. **Think experience-first**: Walk the path from the user's perspective before opening DevTools
-3. **Identify polish areas**:
-   - Visual inconsistencies
-   - Spacing and alignment issues
-   - Interaction state gaps (hover, focus, active, disabled, loading)
-   - Copy inconsistencies and redundancies
-   - Edge cases and error states
-   - Loading and transition smoothness
-   - Information architecture drift
-
-## Polish Checklist
-
-**Visual**
-- [ ] Consistent spacing using the design system scale
-- [ ] Typography hierarchy visible at a glance (size + weight contrast)
-- [ ] Color contrast meets WCAG AA minimums
-- [ ] All interactive elements have hover + focus states
-- [ ] Loading/skeleton states for async content
-- [ ] Empty states designed (not blank)
-
-**Copy**
-- [ ] No restated headings or intros that repeat the title
-- [ ] Error messages are actionable (not "Something went wrong")
-- [ ] No em dashes — use commas, colons, or semicolons
-- [ ] Consistent voice with PRODUCT.md
-
-**Motion**
-- [ ] Transitions feel intentional, not added by reflex
-- [ ] All animations have `prefers-reduced-motion` fallback
-- [ ] No layout-property animation
-
-**Responsive**
-- [ ] All text within viewport, no overflow at any breakpoint
-- [ ] Touch targets ≥44×44px on mobile
-
-## Browser Verification
-
-Use browser automation to verify the live result — don't assume the CSS is correct. Check:
-- The actual user path (not just the happy state)
-- Mobile viewport
-- Dark/light mode switch
-- Keyboard navigation

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

@@ -1,57 +0,0 @@
----
-name: monodesign-quieter
-description: Reduce visual intensity in designs that are too loud, aggressive, or overstimulating — without losing personality or making the result generic.
-type: design-sub-command
-argument-hint: "[target page, component, or design]"
-user-invocable: true
----
-
-# Monodesign: Quieter
-
-Quiet design is harder than bold design. Subtlety needs precision. Read `reference/quieter.md` from the monodesign skill directory for the full protocol.
-
-## Register
-
-**Brand**: "quieter" means more restrained palette, more whitespace, more typographic air. Drama is reduced, not eliminated — the POV stays intact.
-
-**Product**: "quieter" means reducing visual noise. Fewer background accents, flatter cards, less color, less motion. The tool should disappear more completely into the task.
-
-## Assess What's Too Loud
-
-1. **Color saturation**: Overly bright or saturated colors competing for attention
-2. **Contrast extremes**: Too much high-contrast juxtaposition without hierarchy
-3. **Visual weight**: Too many bold, heavy elements with no quiet counterweight
-4. **Animation excess**: Too much motion or overly dramatic effects
-5. **Complexity**: Too many visual elements, patterns, or decorations
-6. **Scale**: Everything is large with no moments of relief
-
-## Quieting Interventions
-
-**Reduce color intensity**
-- Lower chroma on accents (oklab(L, less-C, H))
-- Move from Committed/Full palette to Restrained strategy
-- Replace colored backgrounds with tinted neutrals
-
-**Add breathing room**
-- Increase whitespace between sections
-- Reduce the number of distinct visual elements per screen
-- Let one element be the hero; everything else serves it
-
-**Calm the type**
-- Reduce heading sizes (headline at 3rem vs. 5rem)
-- Use a lighter weight for headings (500 instead of 800)
-- Increase line height and letter-spacing slightly
-
-**Flatten the cards**
-- Remove drop shadows or reduce them to near-invisible (0 1px 2px oklch(0% 0 0 / 0.05))
-- Replace filled card backgrounds with subtle borders or no container at all
-- Reduce border-radius
-
-**Calm the motion**
-- Remove section-fade animations that fire on every element
-- Reduce animation duration by 30–50%
-- Remove hover effects that aren't informative
-
-## The Constraint
-
-Quieter ≠ generic. The goal is precision and restraint, not the absence of a design point of view. If the result could be any brand's product, it's not quieter — it's erased. Preserve the brand's distinctive voice while removing the excess.

package/packages/@monomind/cli/.claude/skills/monodesign/reference/adapt.md

@@ -1,312 +0,0 @@
-> **Additional context needed**: target platforms/devices and usage contexts.
-
-Adapt an existing design to a different context: another screen size, device, platform, or use case. The trap is treating adaptation as scaling. The job is rethinking the experience for the new context.
-
-**Web only** (mobile web included). Native platforms (`ios` / `android` / `adaptive`) route to [adapt.native.md](adapt.native.md) instead; if the project is native, switch to it now.
-
----
-
-## Assess Adaptation Challenge
-
-Understand what needs adaptation and why:
-
-1. **Identify the source context**:
-   - What was it designed for originally? (Desktop web? Mobile app?)
-   - What assumptions were made? (Large screen? Mouse input? Fast connection?)
-   - What works well in current context?
-
-2. **Understand target context**:
-   - **Device**: Mobile, tablet, desktop, TV, watch, print?
-   - **Input method**: Touch, mouse, keyboard, voice, gamepad?
-   - **Screen constraints**: Size, resolution, orientation?
-   - **Connection**: Fast wifi, slow 3G, offline?
-   - **Usage context**: On-the-go vs desk, quick glance vs focused reading?
-   - **User expectations**: What do users expect on this platform?
-
-3. **Identify adaptation challenges**:
-   - What won't fit? (Content, navigation, features)
-   - What won't work? (Hover states on touch, tiny touch targets)
-   - What's inappropriate? (Desktop patterns on mobile, mobile patterns on desktop)
-
-**CRITICAL**: Adaptation is rethinking the experience for the new context, not scaling pixels.
-
-## Plan Adaptation Strategy
-
-Create context-appropriate strategy:
-
-### Mobile Adaptation (Desktop → Mobile)
-
-**Layout Strategy**:
-- Single column instead of multi-column
-- Vertical stacking instead of side-by-side
-- Full-width components instead of fixed widths
-- Bottom navigation instead of top/side navigation
-
-**Interaction Strategy**:
-- Touch targets 44x44px minimum (not hover-dependent)
-- Swipe gestures where appropriate (lists, carousels)
-- Bottom sheets instead of dropdowns
-- Thumbs-first design (controls within thumb reach)
-- Larger tap areas with more spacing
-
-**Content Strategy**:
-- Progressive disclosure (don't show everything at once)
-- Prioritize primary content (secondary content in tabs/accordions)
-- Shorter text (more concise)
-- Larger text (16px minimum)
-
-**Navigation Strategy**:
-- Hamburger menu or bottom navigation
-- Reduce navigation complexity
-- Sticky headers for context
-- Back button in navigation flow
-
-### Tablet Adaptation (Hybrid Approach)
-
-**Layout Strategy**:
-- Two-column layouts (not single or three-column)
-- Side panels for secondary content
-- Master-detail views (list + detail)
-- Adaptive based on orientation (portrait vs landscape)
-
-**Interaction Strategy**:
-- Support both touch and pointer
-- Touch targets 44x44px but allow denser layouts than phone
-- Side navigation drawers
-- Multi-column forms where appropriate
-
-### Desktop Adaptation (Mobile → Desktop)
-
-**Layout Strategy**:
-- Multi-column layouts (use horizontal space)
-- Side navigation always visible
-- Multiple information panels simultaneously
-- Fixed widths with max-width constraints (don't stretch to 4K)
-
-**Interaction Strategy**:
-- Hover states for additional information
-- Keyboard shortcuts
-- Right-click context menus
-- Drag and drop where helpful
-- Multi-select with Shift/Cmd
-
-**Content Strategy**:
-- Show more information upfront (less progressive disclosure)
-- Data tables with many columns
-- Richer visualizations
-- More detailed descriptions
-
-### Print Adaptation (Screen → Print)
-
-**Layout Strategy**:
-- Page breaks at logical points
-- Remove navigation, footer, interactive elements
-- Black and white (or limited color)
-- Proper margins for binding
-
-**Content Strategy**:
-- Expand shortened content (show full URLs, hidden sections)
-- Add page numbers, headers, footers
-- Include metadata (print date, page title)
-- Convert charts to print-friendly versions
-
-### Email Adaptation (Web → Email)
-
-**Layout Strategy**:
-- Narrow width (600px max)
-- Single column only
-- Inline CSS (no external stylesheets)
-- Table-based layouts (for email client compatibility)
-
-**Interaction Strategy**:
-- Large, obvious CTAs (buttons not text links)
-- No hover states (not reliable)
-- Deep links to web app for complex interactions
-
-## Implement Adaptations
-
-Apply changes systematically:
-
-### Responsive Breakpoints
-
-Choose appropriate breakpoints:
-- Mobile: 320px-767px
-- Tablet: 768px-1023px
-- Desktop: 1024px+
-- Or content-driven breakpoints (where design breaks)
-
-### Layout Adaptation Techniques
-
-- **CSS Grid/Flexbox**: Reflow layouts automatically
-- **Container Queries**: Adapt based on container, not viewport
-- **`clamp()`**: Fluid sizing between min and max
-- **Media queries**: Different styles for different contexts
-- **Display properties**: Show/hide elements per context
-
-### Touch Adaptation
-
-- Increase touch target sizes (44x44px minimum)
-- Add more spacing between interactive elements
-- Remove hover-dependent interactions
-- Add touch feedback (ripples, highlights)
-- Consider thumb zones (easier to reach bottom than top)
-
-### Content Adaptation
-
-- Use `display: none` sparingly (still downloads)
-- Progressive enhancement (core content first, enhancements on larger screens)
-- Lazy loading for off-screen content
-- Responsive images (`srcset`, `picture` element)
-
-### Navigation Adaptation
-
-- Transform complex nav to hamburger/drawer on mobile
-- Bottom nav bar for mobile apps
-- Persistent side navigation on desktop
-- Breadcrumbs on smaller screens for context
-
-**IMPORTANT**: Test on real devices. Device emulation in DevTools is helpful but not perfect.
-
-**NEVER**:
-- Hide core functionality on mobile (if it matters, make it work)
-- Assume desktop = powerful device (consider accessibility, older machines)
-- Use different information architecture across contexts (confusing)
-- Break user expectations for platform (mobile users expect mobile patterns)
-- Forget landscape orientation on mobile/tablet
-- Use generic breakpoints blindly (use content-driven breakpoints)
-- Ignore touch on desktop (many desktop devices have touch)
-
-## Verify Adaptations
-
-Test thoroughly across contexts:
-
-- **Real devices**: Test on actual phones, tablets, desktops
-- **Different orientations**: Portrait and landscape
-- **Different browsers**: Safari, Chrome, Firefox, Edge
-- **Different OS**: iOS, Android, Windows, macOS
-- **Different input methods**: Touch, mouse, keyboard
-- **Edge cases**: Very small screens (320px), very large screens (4K)
-- **Slow connections**: Test on throttled network
-
-When the adaptation feels native to each context, hand off to `/monodesign polish` for the final pass.
-
----
-
-## Reference Material
-
-The sections below were previously `responsive-design.md` and live inline now so the adapt flow has its deep responsive reference in one place.
-
-### Responsive Design
-
-#### Mobile-First: Write It Right
-
-Start with base styles for mobile, use `min-width` queries to layer complexity. Desktop-first (`max-width`) means mobile loads unnecessary styles first.
-
-#### Breakpoints: Content-Driven
-
-Don't chase device sizes; let content tell you where to break. Start narrow, stretch until design breaks, add breakpoint there. Three breakpoints usually suffice (640, 768, 1024px). Use `clamp()` for fluid values without breakpoints.
-
-#### Detect Input Method, Not Just Screen Size
-
-**Screen size doesn't tell you input method.** A laptop with touchscreen, a tablet with keyboard. Use pointer and hover queries:
-
-```css
-/* Fine pointer (mouse, trackpad) */
-@media (pointer: fine) {
-  .button { padding: 8px 16px; }
-}
-
-/* Coarse pointer (touch, stylus) */
-@media (pointer: coarse) {
-  .button { padding: 12px 20px; }  /* Larger touch target */
-}
-
-/* Device supports hover */
-@media (hover: hover) {
-  .card:hover { transform: translateY(-2px); }
-}
-
-/* Device doesn't support hover (touch) */
-@media (hover: none) {
-  .card { /* No hover state - use active instead */ }
-}
-```
-
-**Critical**: Don't rely on hover for functionality. Touch users can't hover.
-
-#### Safe Areas: Handle the Notch
-
-Modern phones have notches, rounded corners, and home indicators. Use `env()`:
-
-```css
-body {
-  padding-top: env(safe-area-inset-top);
-  padding-bottom: env(safe-area-inset-bottom);
-  padding-left: env(safe-area-inset-left);
-  padding-right: env(safe-area-inset-right);
-}
-
-/* With fallback */
-.footer {
-  padding-bottom: max(1rem, env(safe-area-inset-bottom));
-}
-```
-
-**Enable viewport-fit** in your meta tag:
-```html
-<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
-```
-
-#### Responsive Images: Get It Right
-
-##### srcset with Width Descriptors
-
-```html
-<img
-  src="hero-800.jpg"
-  srcset="
-    hero-400.jpg 400w,
-    hero-800.jpg 800w,
-    hero-1200.jpg 1200w
-  "
-  sizes="(max-width: 768px) 100vw, 50vw"
-  alt="Hero image"
->
-```
-
-**How it works**:
-- `srcset` lists available images with their actual widths (`w` descriptors)
-- `sizes` tells the browser how wide the image will display
-- Browser picks the best file based on viewport width AND device pixel ratio
-
-##### Picture Element for Art Direction
-
-When you need different crops/compositions (not just resolutions):
-
-```html
-<picture>
-  <source media="(min-width: 768px)" srcset="wide.jpg">
-  <source media="(max-width: 767px)" srcset="tall.jpg">
-  <img src="fallback.jpg" alt="...">
-</picture>
-```
-
-#### Layout Adaptation Patterns
-
-**Navigation**: Three stages: hamburger + drawer on mobile, horizontal compact on tablet, full with labels on desktop. **Tables**: Transform to cards on mobile using `display: block` and `data-label` attributes. **Progressive disclosure**: Use `<details>/<summary>` for content that can collapse on mobile.
-
-#### Testing: Don't Trust DevTools Alone
-
-DevTools device emulation is useful for layout but misses:
-
-- Actual touch interactions
-- Real CPU/memory constraints
-- Network latency patterns
-- Font rendering differences
-- Browser chrome/keyboard appearances
-
-**Test on at least**: One real iPhone, one real Android, a tablet if relevant. Cheap Android phones reveal performance issues you'll never see on simulators.
-
----
-
-**Avoid**: Desktop-first design. Device detection instead of feature detection. Separate mobile/desktop codebases. Ignoring tablet and landscape. Assuming all mobile devices are powerful.

package/packages/@monomind/cli/.claude/skills/monodesign/reference/adapt.native.md

@@ -1,58 +0,0 @@
-> **Additional context needed**: target platforms/devices and usage contexts.
-
-Adapt an existing **native** design (`ios` / `android` / `adaptive`) to a different context: another device class, orientation, platform, or origin. The trap is treating adaptation as scaling. The job is rethinking the experience for the new context, inside the platform conventions of [ios.md](ios.md) / [android.md](android.md); read the target platform's reference before planning if Setup hasn't already.
-
-## Assess Adaptation Challenge
-
-1. **Source context**: what was it designed for, and what assumptions did it make? (Phone-only? Portrait-only? One platform's idioms? A website?)
-2. **Target context**: which device class (phone, tablet, foldable), orientation, platform, and usage posture (one-handed on the go vs two-handed at rest)?
-3. **What breaks**: navigation that doesn't fit the target, layouts that stretch instead of restructure, gestures or controls that don't exist there?
-
-## Adaptation Strategies
-
-### Phone → Tablet (iPad / large screens)
-
-- **Restructure, don't stretch.** A scaled-up phone UI on a tablet is the failure mode. Use size classes (iOS) / window size classes (Android) to switch structure.
-- **Navigation changes shape**: tab bar stays or becomes a sidebar on iPad; Android navigation bar becomes a rail or drawer on expanded width.
-- **Use the width**: split view / master-detail (list + detail side by side), multi-column grids, popovers where phones used sheets.
-- **Multitasking is a size, not an edge case**: iPad Split View and Android multi-window can hand you a phone-width window on a tablet; size-class-driven layout handles both for free.
-
-### Orientation & foldables
-
-- Landscape restructures (side-by-side panes, repositioned controls); never clip or letterbox. Lock orientation only when the task truly demands it.
-- Foldables (Android): react to posture and hinge via window size classes; test folded, unfolded, and tabletop.
-
-### Platform → platform (iOS ↔ Android)
-
-Translate idioms; never transplant them:
-
-| iOS | Android |
-|---|---|
-| Tab bar | Navigation bar / rail / drawer |
-| Edge-swipe back, back chevron | Predictive Back gesture / button |
-| Switch, segmented control, system pickers | Material switch, chips, Material pickers |
-| Action sheet | Bottom sheet / Material dialog |
-| SF Symbols, SF Pro, Dynamic Type | Material Symbols, Roboto, sp scaling |
-| Semantic system colors, materials | Material color roles, tonal elevation |
-| System push/sheet transitions | Container transform, shared-axis, fade-through |
-
-Rebuild navigation and controls in the target's vocabulary; carry over the brand's expressive layer (palette intent, type accent, motion personality) through the target's theming system.
-
-### Web → native (porting a website or web app)
-
-Reconform, don't reflow. Replace web navigation with the platform's model, HTML-shaped controls with platform controls, hover affordances with touch-first ones, and px-based type with Dynamic Type / sp. Then treat the result to the full platform reference; the slop test there is the acceptance bar.
-
-## Implement & Verify
-
-- Drive structure from **size classes / window size classes**, never from device-model checks.
-- Respect safe areas and window insets in every new configuration (notch, hinge, status bar, keyboard).
-- Test on simulators for breadth, then real hardware for truth: at least one phone and one tablet per shipped platform, both orientations, split-screen where supported.
-
-When the adaptation feels native to each context, hand off to `/monodesign polish` for the final pass.
-
-**NEVER**:
-- Ship a stretched phone layout on a tablet
-- Port one platform's controls or navigation onto the other
-- Hide core functionality on smaller devices (if it matters, make it work)
-- Lock orientation to dodge a layout bug
-- Trust simulators alone (posture, gestures, and performance need hardware)

package/packages/@monomind/cli/.claude/skills/monodesign/reference/android.md

@@ -1,40 +0,0 @@
-# Android platform
-
-For native Android apps: Jetpack Compose, Android Views, React Native, Expo, Flutter shipping to Android hardware.
-
-On native, register narrows. Material Design 3 governs structure, navigation, and interaction whatever the register; brand expresses through Material's theming (color roles, type scale, shape, motion). A Material-everywhere cross-platform app that also ships to iPhone still owes iOS its OS guarantees on that hardware: safe-area insets, Reduce Motion, edge-swipe back.
-
-## The Android slop test
-
-Would a fluent Android user trust this app, or trip on off-spec components? The most common tell is an iOS app wearing Android's skin: a bottom-only navigation copied from iPhone, a back arrow that ignores the system Back gesture, Cupertino-shaped switches and dialogs. Material 3 is the rulebook; follow its components and theme the brand through it.
-
-## Layout & structure
-
-- **Material navigation, matched to size.** Navigation bar (bottom, 3–5 destinations) on compact width; navigation rail or drawer on expanded width. Never ship a phone bottom-bar untouched on a tablet.
-- **System Back always works.** Honor the predictive Back gesture and Back button; never trap the user or hijack the gesture.
-- **Edge-to-edge with window insets.** Apply the status bar, navigation bar, display cutout, and IME insets so content never hides behind system bars or the keyboard.
-- **Top app bar for screen context**; pair with a FAB when the screen has a single primary action.
-
-## Touch targets
-
-- **48×48 dp minimum** for every touch target, with at least 8 dp between them.
-
-## Typography
-
-- **Material type scale.** Display, Headline, Title, Body, Label roles (large/medium/small each). Map text to roles; never hand-pick sizes per screen.
-- **Roboto is the system face**; theme a brand face in through the type scale, keeping body, labels, and controls legible and consistent.
-- **sp units, never fixed px**, so type follows the system font-size setting.
-
-## Color & theming
-
-- **Material color roles** (primary, on-primary, surface, surface-variant, secondary-container, outline, error). Role tokens resolve light/dark and contrast variants automatically; raw hex breaks there.
-- **Dynamic Color (Material You)** where it fits: derive the scheme from the user's wallpaper on Android 12+, with a static fallback.
-- **Dark theme is a first-class scheme.** Design and test it; never a quick invert.
-- **Tonal elevation.** Convey elevation through the standard surface tonal levels (plus shadow where appropriate); no arbitrary drop shadows.
-
-## Components & motion
-
-- **Material components.** Buttons (filled / tonal / outlined / text), FAB, switches, chips, snackbars, bottom sheets, Material dialogs, navigation bar/rail/drawer. Never port iOS controls or invent equivalents.
-- **One FAB, one primary action.** Never stack FABs or spend one on a secondary task.
-- **Snackbars for transient feedback** (actionable when useful, never a toast for that); dialogs only for decisions that must interrupt.
-- **Material motion patterns.** Container transform, shared-axis, fade-through, with standard easing and durations; honor the system Remove animations setting with a crossfade or instant cut.