monomind 2.7.12 → 2.7.14

package/packages/@monomind/cli/.claude/skills/monodesign/reference/image-prompts.md

@@ -1,130 +0,0 @@
-# Image Prompts for Design
-
-Generate visual assets — hero imagery, product shots, illustrations, textures — that match the design system and pass the AI slop test.
-
-## Prompt Architecture
-
-Every effective prompt has these layers (order matters):
-
-```
-[Subject] + [Action/pose] + [Environment] + [Lighting] + [Technical specs] + [Style/mood] + [Negative constraints]
-```
-
-Example:
-```
-A UX designer in her mid-30s reviewing wireframes on a large monitor in a modern studio — natural diffused window light — shot on Sony A7III, 85mm f/1.8, shallow depth of field — editorial, desaturated warm tones — NOT stock photo pose, NOT overhead, no fake smile, no extra fingers
-```
-
-## Hero Image Patterns
-
-### Editorial/Product
-```
-[Subject doing real work] in [specific setting], photographed from [angle], 
-[focal length] lens, [lighting condition], [color palette descriptor matching design system],
-cinematic framing — NOT generic stock pose, NOT floating on white
-```
-
-### Abstract Texture/Background
-```
-[Material type] surface, [specific color in OKLCH descriptors], 
-macro photography, [lighting angle], 4K detail — 
-grain: subtle, no harsh shadows, no digital artifacts
-```
-
-### Data Visualization / Illustration
-```
-Clean vector-style illustration, [subject], [color palette: limited to 3 colors], 
-flat design with subtle depth, white/cream background, 
-professional technical style — NOT clipart, NOT gradients, NOT beveled edges
-```
-
-## Inclusive Representation
-
-Default to diversity without tokenism. The goal is accuracy, not optics.
-
-**Do:**
-- Specify age ranges explicitly — "42-year-old" not "middle-aged"
-- Anchor subjects in culturally accurate environments (correct architecture, clothing, props)
-- Use natural lighting that accurately renders different skin tones — diffused or golden hour
-- Include disability representation matter-of-factly: "software engineer using a motorized wheelchair at a standing desk"
-
-**Don't:**
-- Use vague descriptors ("diverse team") — they produce clone faces with name tags
-- Use dramatic lighting that washes out melanin
-- Default to stock-photo "multicultural handshake" compositions
-- Let AI guess on cultural specifics — name them explicitly
-
-**Anti-bias constraints (append to any people prompt):**
-```
-NOT stock photo composition, NOT identical faces, NOT exoticized lighting, 
-realistic proportions, authentic environmental context, 
-no performative diversity staging
-```
-
-## Photography Style by Design Register
-
-### Brand register (landing pages, marketing)
-```
-[Subject], editorial photography style, [season/time], 
-[specific film look: Kodak Portra 400 / CineStill 800T / Fuji Pro 400H],
-natural grain, intentional composition — NOT overprocessed, NOT HDR
-```
-
-### Product register (dashboards, apps)
-```
-Person [performing actual task with product], documentary style,
-environment lighting, candid posture, monitor showing [realistic UI content] —
-NOT posed, NOT smiling at camera, NOT showing screen reflection
-```
-
-## Asset Types and When to Generate
-
-| Asset type | When to generate | When to use CSS instead |
-|---|---|---|
-| Hero background | Abstract, textural, atmospheric | Geometric, color-block, gradient |
-| Person photography | Real human context matters | Illustration suffices |
-| Product screenshots | None — always use real screenshots | — |
-| Icons | Never — use an icon library | Always |
-| Decorative marks / badges | Brand/campaign specific | Logo SVG suffices |
-| Pattern / texture | Surface richness needed | CSS noise/grain pattern |
-| Scene illustration | Concept explanation, empty state | CSS + SVG shapes |
-
-## Image Generation Workflow
-
-1. Write the subject and context first, before any style descriptors
-2. Add lighting explicitly — lighting determines if the image reads as editorial or stock
-3. Add technical specs (lens, camera model) only for photography prompts
-4. Append negative constraints last — they filter, not define
-5. Generate 3 variations at minimum; choose by fit to design brief
-6. Check: Does this pass the "could someone tell AI made this?" test?
-
-### Raster Asset Production Workflow
-
-When a design mock has been approved and needs to be broken into clean, production-ready raster assets (crops, cutouts, textures, clean plates), use the **`monodesign-asset-producer`** agent. It provides a structured production workflow that:
-
-- Classifies each visual role into `produce`, `direct`, or `semantic` buckets
-- Applies the prompt pattern above for image-to-image clean-plate generation
-- Removes baked-in UI chrome (nav, buttons, labels, card borders, shadows) from rasters
-- Hands off semantic elements (icons, logos, charts) to HTML/CSS/SVG with concrete implementation notes
-- Returns a full manifest with `qa_status` for every asset
-
-Invoke it from the parent craft agent when raster production work is scoped: provide the approved mock path, crop ids or a contact sheet, output directory, and format/dimension requirements.
-
-## Prompt Anti-Patterns
-
-| Don't write | Write instead |
-|---|---|
-| "A happy team collaborating" | "Three engineers reviewing a pull request diff on a shared monitor, focused expressions, late afternoon office light" |
-| "Modern business professional" | "CPO at a Series B SaaS company, early 50s, during a strategy session, casual attire" |
-| "Beautiful woman using laptop" | "UX researcher, late 20s, conducting a remote usability interview — double monitor setup, notes visible, concentration" |
-| "Diverse people smiling" | "A four-person product team celebrating a launch, candid shot, conference room with big windows" |
-| "Abstract technology" | "Blurred PCB macro, copper traces, shallow depth of field, cool-toned ambient light" |
-
-## Checking Against the Design System
-
-Before using a generated image:
-1. Color temperature matches design system warm/cool bias
-2. Composition leaves space for text overlay if needed (sky, wall, desk surface)
-3. Image subject doesn't compete with the primary CTA
-4. No logos, recognizable brands, or copyright-compromising content
-5. Accessible alt text can describe this image in one sentence

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

@@ -1,221 +0,0 @@
-# Init Flow
-
-The setup command for a project. One codebase crawl feeds everything it writes:
-
-- **PRODUCT.md** (strategic): root project file for register, target users, product purpose, brand personality, anti-references, strategic design principles. Answers "who/what/why".
-- **DESIGN.md** (visual): root project file for visual theme, color palette, typography, components, layout. Follows the [DESIGN.md format spec](https://raw.githubusercontent.com/google-labs-code/design.md/main/docs/spec.md). Answers "how it looks".
-- **`.monodesign/live/config.json`** (live mode): pre-configured so `/monodesign live` boots straight into variant mode with no first-time detour.
-
-It closes by pointing the user at the best command to run next. Every other monodesign command reads PRODUCT.md and DESIGN.md before doing any work.
-
-## Step 1: Load current state
-
-Check what already exists. PRODUCT.md and DESIGN.md live at the project root, or under `.agents/context/` or `docs/` (case-insensitive). Read whichever are present with your native file tool. Also note whether `.monodesign/live/config.json` already exists (Step 6 leaves it untouched if so).
-
-Decision tree:
-- **Neither file exists (empty project or no context yet)**: do Steps 2-4 (write PRODUCT.md), then decide on DESIGN.md based on whether there's code to analyze.
-- **PRODUCT.md exists, DESIGN.md missing**: skip to Step 5 and offer to run `/monodesign document` for DESIGN.md.
-- **PRODUCT.md exists but has no `## Register` section (legacy)**: add it. Infer a hypothesis from the codebase (see Step 2), confirm with the user, write the field.
-- **PRODUCT.md exists but has no `## Platform` section (legacy)**: add it the same way, but only when the project is native (`ios` / `android` / `adaptive`) or the user wants it explicit; a missing field already means `web`.
-- **Both exist**: STOP and call the AskUserQuestion tool to clarify. Ask which file to refresh. Skip the one the user doesn't want changed.
-- **Just DESIGN.md exists (unusual)**: do Steps 2-4 to produce PRODUCT.md.
-
-Never silently overwrite an existing file. Always confirm first.
-
-If init was invoked as a setup blocker by another command, such as `/monodesign craft landing page`, pause that command here. Complete init, then resume the original command. Your own writes are the freshest source; no reload needed. For craft, resume into shape next; init creates project context, but it is not a substitute for the task-specific shape interview and confirmed design brief.
-
-## Step 2: Explore the codebase
-
-Before asking questions, thoroughly scan the project to discover what you can. This single crawl feeds PRODUCT.md, DESIGN.md, **and** the live-mode framework detection in Step 6, so be thorough once rather than re-scanning later:
-
-- **README and docs**: Project purpose, target audience, any stated goals
-- **Package.json / config files**: Tech stack, dependencies, existing design libraries, **and the framework** (Vite/SPA, Next.js, Nuxt, SvelteKit, Astro, multi-page static) plus the HTML entry the browser actually loads
-- **Existing components**: Current design patterns, spacing, typography in use
-- **Brand assets**: Logos, favicons, color values already defined
-- **Design tokens / CSS variables**: Existing color palettes, font stacks, spacing scales
-- **Any style guides or brand documentation**
-
-Also form a **register hypothesis** from what you find:
-
-- Brand signals: `/`, `/about`, `/pricing`, `/blog/*`, `/docs/*`, hero sections, big typography, scroll-driven sections, landing-page-shaped content.
-- Product signals: `/app/*`, `/dashboard`, `/settings`, `/(auth)`, forms, data tables, side/top nav, app-shell components.
-
-Register is a hypothesis at this point, not a decision; Step 3 confirms it.
-
-Also form a **platform hypothesis**:
-
-- Native signals: React Native / Expo (`react-native`, `expo`), Flutter (`pubspec.yaml`, `flutter`), SwiftUI / UIKit (`.swift`, `.xcodeproj`, an `ios/` app target), Jetpack Compose / Android (`build.gradle`, an `android/` app module, `AndroidManifest.xml`). An `ios/` and/or `android/` directory that is a real app target, not just a Capacitor/Cordova wrapper around a website.
-- Web signals (the default): a web framework (Vite, Next, Nuxt, SvelteKit, Astro), an HTML entry, a CSS/Tailwind setup, no native app target.
-
-Values: `web` / `ios` / `android` / `adaptive` (one codebase, ships both, adapts per OS). Mobile web is still `web`. Like register, this is a hypothesis; Step 3 confirms it.
-
-Note what you've learned and what remains unclear. Also note any rough edges worth a follow-up command (thin hierarchy, flat or gray palette, missing error/empty states, dull copy); Step 7 turns these into concrete recommendations without re-analyzing.
-
-## Step 3: Ask strategic questions (for PRODUCT.md)
-
-STOP and call the AskUserQuestion tool to clarify. Ask about anything the codebase doesn't answer with strong, explicit evidence.
-
-### Interview mode, not confirmation mode
-
-If the repo is empty or the user's brief is sparse, run a short interview before proposing PRODUCT.md. Do **not** turn a one-sentence request into a complete inferred PRODUCT.md and ask for blanket confirmation.
-
-- Use the harness's structured question tool when one exists. Otherwise, ask directly in chat and stop: one question at a time, with lettered options where the crawl suggests likely answers, waiting for each answer before the next.
-- Keep skill vocabulary (register, belief ladder, anti-references) out of question text; ask for the thing in words the user would use. For the brand register, ask like a magazine editor profiling the brand: curious and narrative, drawing out the story, the feel, and what a visitor should come to believe.
-- Ask in focused rounds and wait for answers between them. Keep **one topic per question**; add rounds rather than fold several topics into one either-or choice. Options obey the same rule: an option answers only the question asked; never write a compound option that bundles a feeling with a business outcome or names an additional audience.
-- Use inferred answers as hypotheses or options, not as finished facts.
-- Complete at least one real user-answer round before drafting PRODUCT.md, unless every required answer is directly discoverable from repo docs.
-- Round 1 should establish register, platform, users, purpose, positioning, and desired outcome.
-- Round 2 should establish brand personality or references, anti-references, and accessibility needs, plus conversion & proof for the brand register.
-
-### Minimum viable interview
-
-Ask enough to complete PRODUCT.md. At minimum, cover register confirmation, **platform confirmation** (`web` / `ios` / `android` / `adaptive`), users, purpose, positioning, brand personality, anti-references, and accessibility needs (plus conversion & proof for the brand register) unless each answer is directly discoverable from repo context. Never let the template's default `web` stand unconfirmed for a native or cross-platform repo. After at least one interview round, you may propose inferred answers, but the user must confirm them before you write PRODUCT.md. Never synthesize PRODUCT.md from the original task prompt alone.
-
-### Register (ask first; it shapes everything below)
-
-Every design task is either **brand** (marketing, landing, campaign, long-form content, portfolio: design IS the product) or **product** (app UI, admin, dashboards, tools: design SERVES the product).
-
-If Step 2 produced a clear hypothesis, lead with it: *"From the codebase, this looks like a [brand / product] surface. Does that match your intent, or should we treat it differently?"*
-
-If the signal is genuinely split (e.g. a product with a big marketing landing), STOP and call the AskUserQuestion tool to clarify. Ask which register describes the **primary** surface. The register can be overridden per task later, but PRODUCT.md carries one default. Settle the default before drafting any register-dependent questions; never batch brand-only questions (Conversion & proof) into the same round as the question that decides the register.
-
-### Platform (ask right after register)
-
-Every project targets **web** (includes responsive mobile web), **ios**, **android**, or **adaptive** (one codebase, ships both, adapts per OS: Flutter, React Native, KMP). Platform picks the native rulebook: HIG for `ios`, Material 3 for `android`, both for `adaptive`, none for `web`.
-
-If Step 2 produced a clear hypothesis, lead with it: *"From the codebase, this looks like a [web / ios / android / adaptive] project. Does that match?"* For cross-platform apps, decide by the **design language the app renders**, not the toolchain: one look on both platforms (Flutter's Material-everywhere default) takes that platform's value; genuine per-OS adaptation (Cupertino on iOS, Material on Android) is `adaptive`. When in doubt, `web`.
-
-A monorepo shipping both a website and a native app gets a PRODUCT.md per app, each with its own `## Platform`; the root PRODUCT.md carries the primary surface's platform.
-
-### Users & Purpose
-- Who uses this? What's their context when using it?
-- What job are they trying to get done?
-- What is this for? A purpose stated in README or docs is a hypothesis, not strong evidence; confirm it, don't transcribe it.
-- What does success look like?
-- If more than one kind of user is plausible, confirm a primary and secondary audience; don't manufacture a split that isn't there. An audience implied by another answer (a success metric, a CTA) is still unconfirmed; ask before writing it as secondary.
-- If the surface speaks to a different audience than the people who use the product, ask the user to name both.
-- For brand: what emotions should the interface evoke? (confidence, delight, calm, urgency) Ask this standalone; don't fold emotions into the success question.
-- For product: what workflow are they in? What's the primary task on any given screen?
-
-### Positioning
-- In one line, what does this do that nothing else does? The single strategic claim every screen reinforces.
-
-### Brand & Personality
-- How would you describe the brand personality in 3 words?
-- Reference sites or apps that capture the right feel? What specifically about them?
-  - Push for specific named references with the *specific* thing about them that fits this brand, not generic "modern" adjectives or category-bucket lanes.
-- What should this explicitly NOT look like? Any anti-references?
-
-### Conversion & proof (brand register only)
-- What's the primary CTA?
-- What's the secondary fallback, for visitors not ready for the primary?
-- The one line a visitor should remember after 10 seconds.
-- What must the visitor believe, in order, before taking the primary CTA? (The template's belief ladder.)
-- What proof is on hand? Ask the user to hand over any testimonials, case studies, press, or client/partner logos they already have. If you can receive files directly, collect them; otherwise create `.monodesign/assets/proof/` and ask the user to add files there. Reference supplied files by path; record text proof inline.
-
-### Accessibility & Inclusion
-- Specific accessibility requirements? (WCAG level, known user needs)
-- Considerations for reduced motion, color blindness, or other accommodations?
-
-Skip questions where the answer is already clear. **Do NOT ask about colors, fonts, radii, or visual styling here.** Those belong in DESIGN.md, not PRODUCT.md.
-
-## Step 4: Write PRODUCT.md
-
-Write PRODUCT.md only after the user has confirmed the strategic answers from Step 3. If an inferred answer is uncertain or unconfirmed, ask before writing. Confirmed means what the user actually said yes to; do not pad a confirmed answer with extras they never picked (additional anti-references, audiences, roadmap claims, a WCAG level), whether drawn from the crawl, another answer, or your own option text. If an extra belongs in the doc, ask about it first.
-
-Synthesize into a strategic document:
-
-```markdown
-# Product
-
-## Register
-
-product
-
-## Platform
-
-web
-
-## Users
-[Who they are, their context, the job to be done. Primary audience; a secondary audience or a surface-vs-user split only when they apply.]
-
-## Product Purpose
-[What this product does, why it exists, what success looks like]
-
-## Positioning
-[The single strategic claim every screen reinforces. Not a visual rule, not an anti-reference.]
-
-## Conversion & proof
-[Brand register only. Product register: omit this section entirely, heading included.]
-- Primary and secondary CTA: [...]
-- The line a visitor remembers after 10 seconds: [...]
-- Belief ladder: [...]
-- Proof on hand: [testimonials, case studies, press, or logos, referenced by path]
-
-## Brand Personality
-[Voice, tone, 3-word personality, emotional goals]
-
-## Anti-references
-[What this should NOT look like. Specific bad-example sites or patterns to avoid.]
-
-## Design Principles
-[3-5 strategic principles derived from the conversation. Principles like "practice what you preach", "show, don't tell", "expert confidence". NOT visual rules like "use OKLCH" or "magenta accent".]
-
-## Accessibility & Inclusion
-[WCAG level, known user needs, considerations]
-```
-
-Register is either `brand` or `product` as a bare value. No prose, no commentary. Platform is `web`, `ios`, `android`, or `adaptive`, also a bare value; omit the section only on legacy files you're leaving untouched, otherwise write `web` explicitly.
-
-Write fields as prose, and use bold sparingly: only where a word carries a decision, never as a label lead-in on every line.
-
-Write to `PROJECT_ROOT/PRODUCT.md`. If `.monodesign.md` existed, the loader already renamed it; merge into that content rather than starting from scratch.
-
-## Step 5: Decide on DESIGN.md
-
-Offer `/monodesign document` either way. Two paths:
-
-- **Code exists** (CSS tokens, components, a running site): "I can generate a DESIGN.md that captures your visual system (colors, typography, components) so variants stay on-brand. Want to do that now?"
-- **Pre-implementation** (empty project): "I can seed a starter DESIGN.md from five quick questions about color strategy, type direction, motion energy, and references. You can re-run once there's code, to capture the real tokens. Want to do that now?"
-
-If the user agrees, delegate to `/monodesign document` (it auto-detects scan vs seed). Load its reference and follow that flow.
-
-If the user prefers to skip, mention they can run `/monodesign document` any time later.
-
-## Step 6: Configure live mode (when code exists)
-
-**Skip this step when the platform is native** (`ios` / `android` / `adaptive`): live mode drives a browser overlay. A hybrid wrapper or Expo web target serving HTML doesn't change that.
-
-If the project has code with HTML entries and a dev server (the same "code exists" condition that puts `/monodesign document` in scan mode), pre-configure live mode now. You already identified the framework and the served HTML entry in Step 2, so this is nearly free, and it spares the user the first-time setup detour when they later run `/monodesign live`.
-
-**Skip this step for empty / pre-implementation projects** (nothing to inject into yet). Tell the user live mode will configure itself the first time they run it once there's code.
-
-**If `.monodesign/live/config.json` already exists, leave it untouched** and note that live mode is already configured.
-
-Otherwise:
-
-1. Write `.monodesign/live/config.json`. Choose `files` (the HTML entries the browser actually loads), `insertBefore`, and `commentSyntax` from the framework table in [live.md](live.md)'s **First-time setup** section, using the framework you found in Step 2. That table is canonical; do not restate it here. For multi-page static sites, prefer a glob (`["public/**/*.html"]`) over a literal list.
-2. Run `node .claude/skills/monodesign/scripts/detect-csp.mjs`. If it reports a patchable shape (`append-arrays` / `append-string`), use the **consent prompt template** from live.md before editing any source file. On decline, skip the patch. For `middleware` / `meta-tag` shapes, surface the detected files and ask the user to add `http://localhost:8400` to `script-src` and `connect-src` manually. For `null`, there's nothing to do.
-3. Set `cspChecked: true` in the config once CSP is handled (patched, declined, manual, or not needed). The schema and per-shape patch details live in live.md's First-time setup; follow it rather than duplicating.
-
-Writing the config file is harmless and needs no consent; only the CSP **source-file patch** requires a yes.
-
-## Step 7: Recommend starting points, then wrap up
-
-Summarize tersely:
-- Register captured (brand / product) and platform captured (web / ios / android / adaptive)
-- What was written (PRODUCT.md, DESIGN.md, live config, or a subset)
-- The 3-5 strategic principles from PRODUCT.md that will guide future work
-- If DESIGN.md or live config is pending, one line on how to set it up later
-
-Then recommend the **best commands to run next**, drawn from what your Step 2 crawl already surfaced. Do not run a fresh analysis here; surface observations you already have. Tailor to register **and platform**, offer the 2-4 most relevant (not a menu dump), and give the exact command to type. Group by intent:
-
-- **Build something new**: `/monodesign craft <feature>` (shape, then build end-to-end) or `/monodesign shape <feature>` (plan first). Lead with this for empty or early-stage projects.
-- **Improve what's there**: name the specific surface. `/monodesign critique <page>` for a scored UX review; `/monodesign audit <area>` for a11y / perf / responsive checks; `/monodesign polish <component>` for a pre-ship pass. When the crawl flagged a specific weakness, point the matching command at it: thin hierarchy or spacing → `layout`, flat or gray palette → `colorize`, missing error / empty states → `harden` or `onboard`, dull or unclear copy → `clarify`.
-- **Iterate visually** (web only): `/monodesign live` (configured in Step 6) to pick elements in the browser and generate variants in place. **Skip this group for native platforms.**
-
-The full command menu is one bare `/monodesign` away; keep this list short and pointed.
-
-If init was invoked as a blocker by another monodesign command (e.g. the user ran `/monodesign polish` with no PRODUCT.md), resume that original task now. Your own writes are the freshest source; no reload needed.
-
-Optionally STOP and call the AskUserQuestion tool to clarify. Ask whether they'd like a brief summary of PRODUCT.md appended to CLAUDE.md for easier agent reference. If yes, append a short **Design Context** pointer section there.

package/packages/@monomind/cli/.claude/skills/monodesign/reference/interaction-design.md

@@ -1,189 +0,0 @@
-# Interaction Design
-
-## The Eight Interactive States
-
-Every interactive element needs these states designed:
-
-| State | When | Visual Treatment |
-|-------|------|------------------|
-| **Default** | At rest | Base styling |
-| **Hover** | Pointer over (not touch) | Subtle lift, color shift |
-| **Focus** | Keyboard/programmatic focus | Visible ring (see below) |
-| **Active** | Being pressed | Pressed in, darker |
-| **Disabled** | Not interactive | Reduced opacity, no pointer |
-| **Loading** | Processing | Spinner, skeleton |
-| **Error** | Invalid state | Red border, icon, message |
-| **Success** | Completed | Green check, confirmation |
-
-**The common miss**: Designing hover without focus, or vice versa. They're different. Keyboard users never see hover states.
-
-## Focus Rings: Do Them Right
-
-**Never `outline: none` without replacement.** It's an accessibility violation. Instead, use `:focus-visible` to show focus only for keyboard users:
-
-```css
-/* Hide focus ring for mouse/touch */
-button:focus {
-  outline: none;
-}
-
-/* Show focus ring for keyboard */
-button:focus-visible {
-  outline: 2px solid var(--color-accent);
-  outline-offset: 2px;
-}
-```
-
-**Focus ring design**:
-- High contrast (3:1 minimum against adjacent colors)
-- 2-3px thick
-- Offset from element (not inside it)
-- Consistent across all interactive elements
-
-## Form Design: The Non-Obvious
-
-**Placeholders aren't labels.** They disappear on input. Always use visible `<label>` elements. **Validate on blur**, not on every keystroke (exception: password strength). Place errors **below** fields with `aria-describedby` connecting them.
-
-## Loading States
-
-**Optimistic updates**: Show success immediately, rollback on failure. Use for low-stakes actions (likes, follows), not payments or destructive actions. **Skeleton screens > spinners**: they preview content shape and feel faster than generic spinners.
-
-## Modals: The Inert Approach
-
-Focus trapping in modals used to require complex JavaScript. Now use the `inert` attribute:
-
-```html
-<!-- When modal is open -->
-<main inert>
-  <!-- Content behind modal can't be focused or clicked -->
-</main>
-<dialog open>
-  <h2>Modal Title</h2>
-  <!-- Focus stays inside modal -->
-</dialog>
-```
-
-Or use the native `<dialog>` element:
-
-```javascript
-const dialog = document.querySelector('dialog');
-dialog.showModal();  // Opens with focus trap, closes on Escape
-```
-
-## The Popover API
-
-For tooltips, dropdowns, and non-modal overlays, use native popovers:
-
-```html
-<button popovertarget="menu">Open menu</button>
-<div id="menu" popover>
-  <button>Option 1</button>
-  <button>Option 2</button>
-</div>
-```
-
-**Benefits**: Light-dismiss (click outside closes), proper stacking, no z-index wars, accessible by default.
-
-## Dropdown & Overlay Positioning
-
-Dropdowns rendered with `position: absolute` inside a container that has `overflow: hidden` or `overflow: auto` will be clipped. This is the single most common dropdown bug in generated code.
-
-### CSS Anchor Positioning
-
-The modern solution uses the CSS Anchor Positioning API to tether an overlay to its trigger without JavaScript:
-
-```css
-.trigger {
-  anchor-name: --menu-trigger;
-}
-
-.dropdown {
-  position: fixed;
-  position-anchor: --menu-trigger;
-  position-area: block-end span-inline-end;
-  margin-top: 4px;
-}
-
-/* Flip above if no room below */
-@position-try --flip-above {
-  position-area: block-start span-inline-end;
-  margin-bottom: 4px;
-}
-```
-
-Because the dropdown uses `position: fixed`, it escapes any `overflow` clipping on ancestor elements. The `@position-try` block handles viewport edges automatically. **Browser support**: Chrome 125+, Edge 125+. Not yet in Firefox or Safari - use a fallback for those browsers.
-
-### Popover + Anchor Combo
-
-Combining the Popover API with anchor positioning gives you stacking, light-dismiss, accessibility, and correct positioning in one pattern:
-
-```html
-<button popovertarget="menu" class="trigger">Open</button>
-<div id="menu" popover class="dropdown">
-  <button>Option 1</button>
-  <button>Option 2</button>
-</div>
-```
-
-The `popover` attribute places the element in the **top layer**, which sits above all other content regardless of z-index or overflow. No portal needed.
-
-### Portal / Teleport Pattern
-
-In component frameworks, render the dropdown at the document root and position it with JavaScript:
-
-- **React**: `createPortal(dropdown, document.body)`
-- **Vue**: `<Teleport to="body">`
-- **Svelte**: Use a portal library or mount to `document.body`
-
-Calculate position from the trigger's `getBoundingClientRect()`, then apply `position: fixed` with `top` and `left` values. Recalculate on scroll and resize.
-
-### Fixed Positioning Fallback
-
-For browsers without anchor positioning support, `position: fixed` with manual coordinates avoids overflow clipping:
-
-```css
-.dropdown {
-  position: fixed;
-  /* top/left set via JS from trigger's getBoundingClientRect() */
-}
-```
-
-Check viewport boundaries before rendering. If the dropdown would overflow the bottom edge, flip it above the trigger. If it would overflow the right edge, align it to the trigger's right side instead.
-
-## Destructive Actions: Undo > Confirm
-
-**Undo is better than confirmation dialogs.** Users click through confirmations mindlessly. Remove from UI immediately, show undo toast, actually delete after toast expires. Use confirmation only for truly irreversible actions (account deletion), high-cost actions, or batch operations.
-
-## Keyboard Navigation Patterns
-
-### Roving Tabindex
-
-For component groups (tabs, menu items, radio groups), one item is tabbable; arrow keys move within:
-
-```html
-<div role="tablist">
-  <button role="tab" tabindex="0">Tab 1</button>
-  <button role="tab" tabindex="-1">Tab 2</button>
-  <button role="tab" tabindex="-1">Tab 3</button>
-</div>
-```
-
-Arrow keys move `tabindex="0"` between items. Tab moves to the next component entirely.
-
-### Skip Links
-
-Provide skip links (`<a href="#main-content">Skip to main content</a>`) for keyboard users to jump past navigation. Hide off-screen, show on focus.
-
-## Gesture Discoverability
-
-Swipe-to-delete and similar gestures are invisible. Hint at their existence:
-
-- **Partially reveal**: Show delete button peeking from edge
-- **Onboarding**: Coach marks on first use
-- **Alternative**: Always provide a visible fallback (menu with "Delete")
-
-Don't rely on gestures as the only way to perform actions.
-
----
-
-**Avoid**: Removing focus indicators without alternatives. Using placeholder text as labels. Touch targets <44x44px. Generic error messages. Custom controls without ARIA/keyboard support.

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

@@ -1,45 +0,0 @@
-# iOS platform
-
-For native iOS / iPadOS apps: SwiftUI, UIKit, React Native, Expo, Flutter shipping to Apple hardware.
-
-On native, register narrows. HIG conformance governs structure, navigation, and interaction whatever the register; brand expresses through the expressive layer the platform provides (tint, type, motion, content). Calm, Duolingo, and Spotify carry strong identity entirely inside HIG conventions.
-
-## The iOS slop test
-
-Would a fluent iPhone user trust this app, or pause at off-spec controls? The tell is "ported from a website": reinvented navigation bars, custom back gestures, web-shaped buttons, hover-dependent affordances. Default to the platform's components; depart only for a reason the user would thank you for.
-
-## Layout & structure
-
-- **Safe area.** Lay out inside the safe-area insets. No controls under the notch, Dynamic Island, home indicator, or rounded corners.
-- **System navigation.** Tab bar for 2–5 top-level sections (sections, never actions), navigation stack for hierarchy, sheet for self-contained tasks. No custom global nav, no mixed metaphors.
-- **Edge-swipe back stays alive.** The left-edge back gesture is muscle memory; never disable or overlay it.
-- **Large titles** on top-level screens, collapsing to inline on scroll. Deep detail screens stay inline.
-
-## Touch targets
-
-- **44×44 pt minimum** for every tappable control, with breathing room between adjacent targets.
-
-## Typography
-
-- **Dynamic Type.** Use the system text styles (Large Title through Caption) so text follows the user's reading size. No hard-coded point sizes.
-- **San Francisco carries the UI.** Body, labels, and controls stay on SF Pro / SF Compact; a brand face may appear in display moments.
-- **11 pt floor**; Body is 17 pt.
-
-## Color & materials
-
-- **Semantic system colors** (label, secondaryLabel, systemBackground, separator, tint). They adapt to Dark Mode and increased contrast automatically; raw hex breaks there.
-- **Dark Mode is a first-class appearance.** Design and test both.
-- **One tint color** drives interactive elements; decoration is not its job.
-- **System materials** for blur and translucency behind bars and sheets; no hand-rolled glassmorphism.
-
-## Components & controls
-
-- **Platform controls.** Switch, segmented control, stepper, system pickers, action sheets, alerts, context menus, swipe actions. Reinventing these for flavor is the most common native slop.
-- **SF Symbols** for iconography: baseline-aligned, Dynamic Type-aware, weight and scale variants. Don't mix in a web icon set.
-- **Deliberate modality.** Sheet for a focused dismissible sub-task, full-screen cover for immersion. Clear Cancel/Done; honor swipe-to-dismiss unless data loss requires a guard.
-- **Grouped/inset lists** for settings-shaped content; no bespoke card stacks.
-
-## Motion
-
-- **System transitions.** Push slides, sheets rise, dismiss reverses the entrance. Custom transitions that fight the navigation model disorient.
-- **Honor Reduce Motion.** Crossfade instead of parallax and large slides.