@dryui/ui 2.0.2 → 4.0.0

package/skills/dryui/SKILL.md

@@ -1,308 +0,0 @@
----
-name: dryui
-description: 'Use when building UIs with DryUI (@dryui/ui) Svelte 5 components. Teaches correct patterns for compound components, theming, forms, and accessibility. Use the CLI as the default entry point; MCP mirrors the same workflow when available.'
----
-
-# DryUI
-
-Zero-dependency Svelte 5 components. All imports from `@dryui/ui`. Requires a theme CSS import. Svelte 5 runes only.
-
-**Tradeoff:** These rules bias toward correctness over speed. For throwaway prototypes, use judgment.
-
-## UI Creation Pipeline
-
-DryUI work is explicit. Do the design thinking where the user can see it, then validate the result.
-
-1. **User brief** — capture audience, job-to-be-done, product/domain, constraints, and any existing design direction.
-2. **DESIGN.md identity** — read or create the local design identity before choosing components. Google-style `DESIGN.md` is a supported optional format, not a required dependency.
-3. **DryUI lookup/plan** — use `dryui info`, `dryui compose`, or MCP `ask` to confirm component contracts, tokens, layout rules, and recipes.
-4. **make-interfaces-feel-better polish intent pass** — state which polish details matter for this screen before implementation. This is an explicit planning step, not hidden taste.
-5. **Implementation** — build with DryUI components, Svelte 5, grid layout, tokens, and accessible composition.
-6. **Deterministic check** — run `dryui check [path]` or MCP `check` to catch contracts, accessibility, tokens, and CSS discipline.
-7. **Visual review** — run `dryui check --visual <url>` or MCP `check` with `visualUrl`; include the make-interfaces-feel-better rubric in the review intent.
-8. **Repair loop** — fix the highest-signal issues, then repeat deterministic check and visual review until the UI matches the brief.
-
-Precedence when guidance conflicts:
-
-1. User intent and task constraints.
-2. Local `DESIGN.md` identity.
-3. DryUI component contracts, accessibility rules, and token/theming discipline.
-4. Official Svelte MCP guidance for Svelte and SvelteKit syntax/framework questions.
-5. make-interfaces-feel-better polish rubric.
-
-## 1. Look Up Before You Write
-
-**Never guess a component API. Always verify first.**
-
-- Call `dryui info <component>` or `dryui compose "<query>"` before using any component for the first time. If MCP is available, `ask --scope component` and `ask --scope recipe` are equivalent.
-- Component APIs vary — `bind:value`, `bind:open`, `bind:checked` are NOT interchangeable
-- Compound vs simple, required parts, available props — all differ per component
-- If you skip the lookup, you'll write plausible-looking code that silently breaks
-
-The test: can you point to a `dryui info`, `dryui compose`, or `ask` call for every component or pattern in your output?
-
-## 2. Everything is Compound Until Proven Otherwise
-
-**Use `.Root`. Always check.**
-
-Most DryUI components are compound — they require `<Card.Root>`, not `<Card>`. The bare name silently fails or renders wrong. Assume compound; verify with `dryui info <Component>` or `ask --scope component`.
-
-```svelte
-<!-- Wrong -->
-<Card>content</Card>
-<!-- Right -->
-<Card.Root>content</Card.Root>
-```
-
-Compound components are tracked in the manifest at `packages/mcp/src/component-catalog.ts`. Verify with `dryui info <Component>` or `ask --scope component` before you assume a bare name works, then use `.Root` and wrap the parts inside it.
-
-The test: every compound component in your markup uses `.Root`, and its parts are wrapped inside it. See `rules/compound-components.md` for the parts reference.
-
-## 3. Let the Theme Do Its Job
-
-**Import it. Use its tokens. Don't fight it.**
-
-- Import `@dryui/ui/themes/default.css` (and `dark.css`) before any component use
-- Use `--dry-color-*` and `--dry-space-*` tokens — never hardcoded colors or spacing
-- Don't add decorative CSS (gradients, shadows, colored borders) — the theme handles appearance
-- Override semantic tokens (Tier 2) in `:root`, not component tokens (Tier 3)
-- Prefer `<html class="theme-auto">` — use `data-theme="light|dark"` only for explicit overrides
-
-```css
-/* Wrong */
-.card {
-	background: #6366f1;
-	color: white;
-}
-
-/* Right */
-.card {
-	background: var(--dry-color-fill-brand);
-	color: var(--dry-color-text-strong);
-}
-```
-
-The test: does your CSS contain zero hex colors, zero `rgb()` values, and zero inline styles?
-
-## 4. Grid for Layout. Container for Width. @container for Responsive.
-
-**Nothing else.**
-
-- All layout is `display: grid` with `--dry-space-*` tokens in scoped `<style>`
-- `Container` (simple component, no `.Root`) for constrained content width
-- Use `@container` queries for responsive sizing — never `@media` for layout breakpoints
-- No flexbox. No inline styles. No `width`/`min-width`/`max-width` properties
-
-```svelte
-<div class="layout">...</div>
-
-<style>
-	.layout {
-		display: grid;
-		gap: var(--dry-space-4);
-	}
-</style>
-```
-
-The test: grep your output for `display: flex`, `style=`, `@media` — all should return nothing.
-
-## 4A. Escape Hatches Mean Stop.
-
-**If lint or the compiler pushes you toward an escape hatch, the structure is usually wrong.**
-
-- Never add `:global()`, `!important`, `all: unset`, `<svelte:element>`, or `<!-- svelte-ignore ... -->` just to make a selector or warning go away
-- Never add `width`, `min-width`, `max-width`, `inline-size`, `min-inline-size`, or `max-inline-size` to solve layout pressure
-- Never use raw native elements outside their canonical DryUI component directories just because composition feels inconvenient
-- Never pass `class=` to DryUI components expecting it to style their internals; use wrapper elements, component props, `data-*` attributes, or `--dry-*` tokens instead
-- When blocked, restructure the markup instead: add a local wrapper, split explicit `{#if}` branches, move sizing to parent grid tracks, or promote the pattern into the canonical component where the raw element belongs
-- Treat `dryui/no-global`, `dryui/no-important`, `dryui/no-width`, `dryui/no-raw-native-element`, `dryui/no-css-ignore`, and `dryui/no-svelte-element` as design feedback, not obstacles to suppress
-
-The test: grep your output for `:global(`, `!important`, `all: unset`, `svelte-ignore`, `svelte:element`, raw `<button`, raw `<input`, raw `<select`, raw `<dialog`, raw `<hr`, raw `<table`, and `width:` — all should return nothing unless you are editing the canonical component that owns that native element.
-
-## 5. Every Input Gets a Field.Root
-
-**Accessibility isn't optional.**
-
-- Wrap every form input in `Field.Root` with a `Label`
-- Use `AlertDialog` (not `Dialog`) for destructive confirmations
-- Add `aria-label` to every icon-only button
-- Use `type="submit"` on primary form action buttons
-
-```svelte
-<!-- Wrong -->
-<label>Email</label>
-<Input bind:value={email} />
-
-<!-- Right -->
-<Field.Root>
-	<Label>Email</Label>
-	<Input bind:value={email} />
-</Field.Root>
-```
-
-The test: every `<Input>`, `<Select.Root>`, `<Textarea>` is inside a `Field.Root` with a `Label` sibling.
-
-## 6. Prefer DryUI Over Native HTML
-
-**If a DryUI component exists for it, use it.**
-
-`DatePicker` not `<input type="date">`. `Select.Root` not `<select>`. `Dialog.Root` not `<dialog>`. `Separator` not `<hr>`. `Button` not `<button>`. DryUI components handle theming and accessibility automatically — native elements don't.
-
-The test: search your markup for raw `<input`, `<select>`, `<dialog>`, `<button>`, `<hr>`, `<table>` — each should be a DryUI component instead.
-
-## 7. Ask the Svelte MCP for Svelte Questions
-
-**DryUI owns components. `@sveltejs/mcp` owns the framework.**
-
-For Svelte 5 runes (`$state`, `$derived`, `$effect`, `$props`), snippets, SvelteKit load fns, `+page.server.ts` shape, form actions, and anything Svelte-syntax adjacent: call the official `svelte-autofixer` and `get-documentation` tools from `@sveltejs/mcp` before guessing from memory.
-
-- `dryui setup --install` registers `@sveltejs/mcp` by default; pass `--no-svelte-mcp` to skip.
-- If it's not registered, the fallback is the remote endpoint `https://mcp.svelte.dev/mcp` or a one-liner like `claude mcp add -t stdio -s user svelte -- npx -y @sveltejs/mcp`.
-- Scope split: DryUI `ask`/`check` cover component APIs, theming, composition, and validation. Svelte MCP covers the runtime, compiler, and framework idioms.
-
-The test: before writing non-trivial Svelte 5 or SvelteKit code, did you either (a) call `svelte-autofixer` / `get-documentation`, or (b) confirm the pattern is already covered by a DryUI recipe via `ask --scope recipe`?
-
-## Quick Start
-
-**1. Install the CLI** so every subsequent command is short and fast:
-
-```bash
-bun install -g @dryui/cli@latest   # or: npm install -g @dryui/cli@latest
-```
-
-**2. Start with bare `dryui`** when you want editor integration and feedback:
-
-```bash
-dryui
-```
-
-**3. Bootstrap or inspect the project** with the CLI:
-
-```bash
-dryui init             # existing project
-dryui init my-app      # new project — scaffolds SvelteKit + DryUI in one step
-cd my-app && bun run dev
-```
-
-This works for greenfield (empty directory), brownfield (existing non-SvelteKit project), and existing SvelteKit projects. On existing projects, `dryui install` prints the ordered plan and `dryui detect` verifies that setup is complete.
-
-> **No global install?** `bunx @dryui/cli <cmd>` and `npx -y @dryui/cli <cmd>` work anywhere without installing — same commands, just slower (re-fetches on each call).
-
-**4. Add the editor integration layer** after the CLI is working:
-
-- Claude Code: `claude plugin marketplace add rob-balfre/dryui && claude plugin install dryui@dryui` (plugin is the canonical Claude skill install path)
-- Codex (0.121.0+): `codex marketplace add rob-balfre/dryui`, then start `codex`, run `/plugins`, and install `DryUI` (plugin is the canonical Codex skill install path)
-- OpenCode: `npx degit rob-balfre/dryui/packages/ui/skills/dryui .opencode/skills/dryui` + add the `dryui` and `dryui-feedback` local MCP servers in `opencode.json` (OpenCode also loads `.agents/skills/dryui` and reads `AGENTS.md`)
-- Copilot/Cursor/Windsurf: `npx degit rob-balfre/dryui/packages/ui/skills/dryui .agents/skills/dryui` + add MCP config (see https://dryui.dev/tools)
-
-**5. Register the Svelte MCP companion.** `dryui setup --install` does this automatically for Copilot, Cursor, OpenCode, Windsurf, and Zed. For Claude Code run `claude mcp add -t stdio -s user svelte -- npx -y @sveltejs/mcp`; for Codex add `[mcp_servers.svelte] command = "npx", args = ["-y", "@sveltejs/mcp"]` to `~/.codex/config.toml`. See rule 7 above.
-
-### Manual setup
-
-1. `bun add @dryui/ui`
-2. `bun add -d @dryui/lint` — enforces grid-only layout, bans flexbox/inline-style/width at build time. Without this step the CSS discipline rules are not enforced at build time, and only post-write `check` / CLI validation remain.
-3. Wire the lint preprocessor in `svelte.config.js` (add `dryuiLint` as the **first** item in the `preprocess` array):
-
-   ```js
-   import { dryuiLint } from '@dryui/lint';
-
-   /** @type {import('@sveltejs/kit').Config} */
-   const config = {
-   	preprocess: [
-   		dryuiLint({
-   			strict: true,
-   			exclude: ['.svelte-kit/', '/dist/']
-   		})
-   		// keep any existing preprocessors after this
-   	]
-   };
-
-   export default config;
-   ```
-
-4. Add `class="theme-auto"` to `<html>` in `src/app.html`
-5. In root layout (`src/routes/+layout.svelte`), import themes:
-   ```svelte
-   <script>
-   	import '@dryui/ui/themes/default.css';
-   	import '@dryui/ui/themes/dark.css';
-   </script>
-   ```
-6. Import `app.css` AFTER theme CSS if you have custom styles
-
-> `dryui init` applies all six steps automatically — prefer it over manual setup when you can.
-
-## Bindable Props — Common Confusion
-
-Always verify with `dryui info <Component>` or `ask --scope component`, but these are the most common mistakes:
-
-- `bind:value` (Input, Select, Tabs...) vs `bind:checked` (Checkbox, Switch) vs `bind:pressed` (Toggle) vs `bind:open` (Dialog, Popover, Drawer...)
-- Select and Combobox support both `bind:value` and `bind:open`
-- ColorPicker also exposes `bind:alpha`; Transfer uses `bind:sourceItems` / `bind:targetItems`
-- Tour uses `bind:active`, not `bind:open`
-
-## Tools
-
-Use these to look up APIs, discover components, plan setup, and validate code.
-
-### Recommended workflow
-
-1. Start from the user brief and local `DESIGN.md` identity, then resolve any component or recipe uncertainty with `dryui info <Component>` or `dryui compose "<query>"`. If MCP is available, `ask --scope component` and `ask --scope recipe` are the equivalent surface.
-2. Before writing code, make an explicit make-interfaces-feel-better polish intent pass: text wrapping, radius, icon motion, numbers, transitions, entrances/exits, shadows, icon alignment, image edges, and token consistency.
-3. Build the route or component with raw CSS grid, `Container` for constrained width, and `@container` for responsive layout.
-4. Run `dryui check [path]` or MCP `check` after implementation to catch composition drift, layout violations, accessibility regressions, and token drift.
-5. Run `dryui check --visual <url>` or MCP `check` with `visualUrl` for rendered review, then repair and repeat until the UI satisfies the brief.
-6. Never guess component shape from memory. DryUI is intentionally strict, and the lookup cost is lower than rework.
-
-### CLI (default entry point)
-
-Install once with `bun install -g @dryui/cli@latest` (or `npm install -g @dryui/cli@latest`), then use the short form below. Every command outputs TOON (token-optimized, agent-friendly) by default. Pass `--text` for human-readable plain text, `--json` where supported, or `--full` to disable truncation.
-
-```bash
-dryui                           # default onboarding entry point
-dryui setup                     # explicit onboarding subcommand
-dryui init [path] [--pm bun]    # Bootstrap SvelteKit + DryUI project
-dryui info <component>          # Look up component API
-dryui compose "date input"      # Composition guidance
-dryui detect [path]             # Check project setup
-dryui install [path]            # Print install plan
-dryui check [path]              # Validate file, theme, directory, or workspace
-dryui check --visual <url>      # Screenshot a URL and critique rendered polish
-dryui list                      # List components
-dryui tokens --category color   # Browse design tokens
-dryui ambient                   # SessionStart context
-dryui install-hook --dry-run    # Preview Claude hook wiring
-dryui feedback init             # Feedback tooling setup
-```
-
-Without a global install, prefix any command with `bunx @dryui/cli …` or `npx -y @dryui/cli …` — same behaviour, just slower (re-fetches on each call).
-
-### MCP tools (same workflow in-editor)
-
-| Workflow             | Tools                                                             |
-| -------------------- | ----------------------------------------------------------------- |
-| Project setup        | `ask --scope setup ""`                                            |
-| Lookup & composition | `ask --scope component`, `ask --scope recipe`, `ask --scope list` |
-| Validation           | `check <file.svelte>`, `check <theme.css>`                        |
-| Audit                | `check`, `check <directory>`                                      |
-| Rendered UI          | `check` with `visualUrl`, or direct `check-vision`                |
-
-Categories: action, input, form, layout, navigation, overlay, display, feedback, interaction, utility
-
-## Rule Files
-
-Read these when you need deeper guidance:
-
-- **`rules/compound-components.md`** — Parts lists, component selection table, common mistakes
-- **`rules/theming.md`** — Three-tier token system, dark mode, palette customization
-- **`rules/composition.md`** — Form patterns, page layouts, composition recipes
-- **`rules/accessibility.md`** — Field.Root, ARIA, focus management, pre-ship checklist
-- **`rules/svelte.md`** — Runes, snippets, native browser APIs, styling rules
-- **`rules/design.md`** — Minimal code, no premature abstraction, naming conventions
-- **`rules/design-brief.md`** — User brief, DESIGN.md identity, precedence, and polish review pipeline
-- **`rules/visual-effects-performance.md`** — Tiered budgets and implementation rules for shader, blur, glass, and pointer-reactive effects
-- **`rules/native-web-transitions.md`** — View Transition API, scroll animations, reduced-motion
-
----
-
-**These rules are working if:** every component traces to a lookup, diffs contain zero hardcoded colors, and the reviewer finds nothing.

package/skills/dryui/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: 'DryUI'
-  short_description: 'Zero-dependency Svelte 5 component library patterns'
-  default_prompt: 'Use $dryui to build with correct compound components, theming, accessibility, and composition patterns.'
-
-dependencies:
-  tools:
-    - type: 'mcp'
-      value: 'dryui'
-      description: 'DryUI component lookup, validation, composition guidance, and project planning'

package/skills/dryui/rules/accessibility.md

@@ -1,215 +0,0 @@
-# Accessibility
-
-## Field.Root for Form Inputs
-
-Field.Root generates unique IDs and links Label to the input via `for`/`id` attributes. Always use it instead of raw `<label>` elements.
-
-```svelte
-<!-- Incorrect: label not linked to input -->
-<label>Email</label>
-<Input bind:value={email} />
-
-<!-- Correct: Field.Root handles accessible linking -->
-<Field.Root>
-	<Label>Email</Label>
-	<Input bind:value={email} />
-</Field.Root>
-```
-
-Field.Root also connects Description and Error parts via `aria-describedby`:
-
-```svelte
-<Field.Root>
-	<Label>Password</Label>
-	<Input type="password" bind:value={password} />
-	<Field.Description>Must be at least 8 characters.</Field.Description>
-	<Field.Error>Password is too short.</Field.Error>
-</Field.Root>
-```
-
-This produces the correct ARIA relationships automatically:
-
-- Label is linked to the input via `for`/`id`
-- Description is linked via `aria-describedby`
-- Error is linked via `aria-describedby` and sets `aria-invalid` on the input
-
-## Dialog and AlertDialog
-
-### Dialog
-
-Dialog traps focus inside the overlay. Always provide a title and a way to close.
-
-```svelte
-<!-- Incorrect: dialog without header or close mechanism -->
-<Dialog.Root bind:open={show}>
-	<Dialog.Content>
-		<p>Some content</p>
-	</Dialog.Content>
-</Dialog.Root>
-
-<!-- Correct: header provides accessible title, close button available -->
-<Dialog.Root bind:open={show}>
-	<Dialog.Trigger>
-		<Button>Open</Button>
-	</Dialog.Trigger>
-	<Dialog.Content>
-		<Dialog.Header>Edit Profile</Dialog.Header>
-		<Dialog.Body>
-			<Field.Root>
-				<Label>Name</Label>
-				<Input bind:value={name} />
-			</Field.Root>
-		</Dialog.Body>
-		<Dialog.Footer>
-			<Button variant="outline" onclick={() => (show = false)}>Cancel</Button>
-			<Button variant="solid">Save</Button>
-		</Dialog.Footer>
-	</Dialog.Content>
-</Dialog.Root>
-```
-
-### AlertDialog
-
-Use AlertDialog (not Dialog) for destructive confirmations. It requires explicit user action and cannot be dismissed by clicking the overlay.
-
-```svelte
-<!-- Incorrect: using Dialog for destructive confirmation -->
-<Dialog.Root bind:open={showDelete}>
-	<Dialog.Content>
-		<p>Delete this item?</p>
-		<Button onclick={handleDelete}>Delete</Button>
-	</Dialog.Content>
-</Dialog.Root>
-
-<!-- Correct: AlertDialog with Action and Cancel parts -->
-<AlertDialog.Root>
-	<AlertDialog.Trigger>
-		<Button variant="outline">Delete</Button>
-	</AlertDialog.Trigger>
-	<AlertDialog.Content>
-		<AlertDialog.Header>Delete Item</AlertDialog.Header>
-		<AlertDialog.Body>
-			<p>This action cannot be undone.</p>
-		</AlertDialog.Body>
-		<AlertDialog.Footer>
-			<AlertDialog.Cancel>Cancel</AlertDialog.Cancel>
-			<AlertDialog.Action>Delete</AlertDialog.Action>
-		</AlertDialog.Footer>
-	</AlertDialog.Content>
-</AlertDialog.Root>
-```
-
-## Button vs Anchor
-
-Use Button for actions. Use `<a>` for navigation.
-
-```svelte
-<!-- Incorrect: anchor styled as action button -->
-<a href="#" onclick={handleSave}>Save</a>
-
-<!-- Correct: Button for actions -->
-<Button onclick={handleSave}>Save</Button>
-
-<!-- Correct: anchor for navigation -->
-<a href="/settings">Go to Settings</a>
-```
-
-## Icon-Only Buttons
-
-Always add `aria-label` to buttons that contain only an icon and no visible text.
-
-```svelte
-<!-- Incorrect: icon button without accessible name -->
-<Button variant="ghost" onclick={toggleMenu}>
-	<MenuIcon />
-</Button>
-
-<!-- Correct: aria-label provides accessible name -->
-<Button variant="ghost" onclick={toggleMenu} aria-label="Open menu">
-	<MenuIcon />
-</Button>
-```
-
-## Avatar
-
-Always provide `alt` text for Avatar images.
-
-```svelte
-<!-- Incorrect: no alt text -->
-<Avatar src="/photo.jpg" />
-
-<!-- Correct: descriptive alt text -->
-<Avatar src="/photo.jpg" alt="Jane Doe's profile photo" />
-```
-
-## Keyboard Navigation
-
-DryUI components handle keyboard navigation automatically:
-
-- **Tabs**: Arrow keys move between triggers, Enter/Space activates
-- **Accordion**: Arrow keys navigate triggers, Enter/Space toggles
-- **DropdownMenu**: Arrow keys navigate items, Enter selects, Escape closes
-- **Select**: Arrow keys navigate items, Enter selects, Escape closes
-- **Dialog/AlertDialog**: Tab cycles through focusable elements, Escape closes (Dialog only)
-
-No extra code needed for standard keyboard behavior. Avoid overriding `onkeydown` on these components unless you have a specific accessibility need.
-
-## Form Submission
-
-Use `type="submit"` on the primary form action button so that pressing Enter in any input submits the form.
-
-```svelte
-<!-- Incorrect: button without type, won't submit on Enter -->
-<form onsubmit={handleSubmit}>
-	<Field.Root>
-		<Label>Search</Label>
-		<Input bind:value={query} />
-	</Field.Root>
-	<Button variant="solid" onclick={handleSubmit}>Search</Button>
-</form>
-
-<!-- Correct: type="submit" enables Enter key submission -->
-<form onsubmit={handleSubmit}>
-	<Field.Root>
-		<Label>Search</Label>
-		<Input bind:value={query} />
-	</Field.Root>
-	<Button type="submit" variant="solid">Search</Button>
-</form>
-```
-
-## Loading States
-
-Use `disabled` and descriptive text or `aria-label` during loading states.
-
-```svelte
-<!-- Incorrect: no indication of loading -->
-<Button onclick={save}>
-	{#if saving}
-		<Spinner />
-	{:else}
-		Save
-	{/if}
-</Button>
-
-<!-- Correct: disabled and labeled during loading -->
-<Button onclick={save} disabled={saving} aria-label={saving ? 'Saving...' : undefined}>
-	{#if saving}
-		<Spinner /> Saving...
-	{:else}
-		Save
-	{/if}
-</Button>
-```
-
-## Checklist
-
-Before shipping a page with DryUI components:
-
-1. Every form input is wrapped in `Field.Root` with a `Label`
-2. Every Dialog/AlertDialog has a header or `aria-label`
-3. Every icon-only Button has `aria-label`
-4. Destructive confirmations use `AlertDialog`, not `Dialog`
-5. Primary form buttons use `type="submit"`
-6. Avatar images have `alt` text
-7. No `<a href="#">` used as action buttons