@dryui/ui 2.0.2 → 4.0.0

package/skills/dryui/rules/compound-components.md

@@ -1,312 +0,0 @@
-# Compound Components
-
-## Core Rule
-
-Every compound component uses `.Root` as the container. Never use the bare name.
-
-```svelte
-<!-- Incorrect -->
-<Card>...</Card>
-<Dialog>...</Dialog>
-<Tabs>...</Tabs>
-
-<!-- Correct -->
-<Card.Root>...</Card.Root>
-<Dialog.Root>...</Dialog.Root>
-<Tabs.Root>...</Tabs.Root>
-```
-
-## Parts Reference
-
-Below are the parts for the most commonly used compound components. Prefer `dryui info <name>` for the full, up-to-date parts list; if MCP is available, `ask --scope component "<name>"` is equivalent.
-
-### Card
-
-Parts: Root, Header, Content, Footer
-
-```svelte
-<Card.Root>
-	<Card.Header>Title</Card.Header>
-	<Card.Content>
-		<p>Body content goes here.</p>
-	</Card.Content>
-	<Card.Footer>
-		<Button variant="solid">Action</Button>
-	</Card.Footer>
-</Card.Root>
-```
-
-### Dialog
-
-Parts: Root, Trigger, Content, Overlay, Header, Body, Footer, Close
-
-```svelte
-<script>
-	let showDialog = $state(false);
-</script>
-
-<Dialog.Root bind:open={showDialog}>
-	<Dialog.Trigger>
-		<Button>Open Dialog</Button>
-	</Dialog.Trigger>
-	<Dialog.Content>
-		<Dialog.Header>Confirm Action</Dialog.Header>
-		<Dialog.Body>
-			<p>Are you sure you want to proceed?</p>
-		</Dialog.Body>
-		<Dialog.Footer>
-			<Button variant="outline" onclick={() => (showDialog = false)}>Cancel</Button>
-			<Button variant="solid">Confirm</Button>
-		</Dialog.Footer>
-	</Dialog.Content>
-</Dialog.Root>
-```
-
-### Drawer
-
-Parts: Root, Trigger, Content, Overlay, Header, Body, Footer, Close
-
-Same structure as Dialog but slides in from the side.
-
-```svelte
-<script>
-	let showDrawer = $state(false);
-</script>
-
-<Drawer.Root bind:open={showDrawer}>
-	<Drawer.Trigger>
-		<Button>Open Drawer</Button>
-	</Drawer.Trigger>
-	<Drawer.Content>
-		<Drawer.Header>Settings</Drawer.Header>
-		<Drawer.Body>
-			<p>Drawer content here.</p>
-		</Drawer.Body>
-		<Drawer.Footer>
-			<Button variant="solid">Save</Button>
-		</Drawer.Footer>
-	</Drawer.Content>
-</Drawer.Root>
-```
-
-### Tabs
-
-Parts: Root, List, Trigger, Content
-
-Use `bind:value` on Root to track the active tab.
-
-```svelte
-<script>
-	let activeTab = $state('one');
-</script>
-
-<Tabs.Root bind:value={activeTab}>
-	<Tabs.List>
-		<Tabs.Trigger value="one">Tab 1</Tabs.Trigger>
-		<Tabs.Trigger value="two">Tab 2</Tabs.Trigger>
-	</Tabs.List>
-	<Tabs.Content value="one">First panel</Tabs.Content>
-	<Tabs.Content value="two">Second panel</Tabs.Content>
-</Tabs.Root>
-```
-
-### Accordion
-
-Parts: Root, Item, Trigger, Content
-
-```svelte
-<Accordion.Root>
-	<Accordion.Item value="a">
-		<Accordion.Trigger>Section A</Accordion.Trigger>
-		<Accordion.Content>Content for section A.</Accordion.Content>
-	</Accordion.Item>
-	<Accordion.Item value="b">
-		<Accordion.Trigger>Section B</Accordion.Trigger>
-		<Accordion.Content>Content for section B.</Accordion.Content>
-	</Accordion.Item>
-</Accordion.Root>
-```
-
-### AlertDialog
-
-Parts: Root, Trigger, Content, Overlay, Header, Body, Footer, Action, Cancel
-
-Use AlertDialog for destructive confirmations. It traps focus and requires explicit user action.
-
-```svelte
-<AlertDialog.Root>
-	<AlertDialog.Trigger>
-		<Button variant="outline">Delete Account</Button>
-	</AlertDialog.Trigger>
-	<AlertDialog.Content>
-		<AlertDialog.Header>Are you sure?</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>
-```
-
-### DropdownMenu
-
-Parts: Root, Trigger, Content, Item, Separator, Group, Label
-
-```svelte
-<DropdownMenu.Root>
-	<DropdownMenu.Trigger>
-		<Button variant="outline">Options</Button>
-	</DropdownMenu.Trigger>
-	<DropdownMenu.Content>
-		<DropdownMenu.Item onclick={handleEdit}>Edit</DropdownMenu.Item>
-		<DropdownMenu.Item onclick={handleDuplicate}>Duplicate</DropdownMenu.Item>
-		<DropdownMenu.Separator />
-		<DropdownMenu.Item onclick={handleDelete}>Delete</DropdownMenu.Item>
-	</DropdownMenu.Content>
-</DropdownMenu.Root>
-```
-
-### Select
-
-Parts: Root, Trigger, Content, Item, Value
-
-```svelte
-<script>
-	let selected = $state('');
-</script>
-
-<Select.Root bind:value={selected}>
-	<Select.Trigger>
-		<Select.Value placeholder="Choose..." />
-	</Select.Trigger>
-	<Select.Content>
-		<Select.Item value="a">Alpha</Select.Item>
-		<Select.Item value="b">Beta</Select.Item>
-		<Select.Item value="c">Gamma</Select.Item>
-	</Select.Content>
-</Select.Root>
-```
-
-### Field
-
-Parts: Root, Description, Error
-
-Field.Root wraps a Label and input component. The Label and input (Input, Select, Textarea, etc.) are direct children, not Field parts.
-
-```svelte
-<Field.Root>
-	<Label>Username</Label>
-	<Input bind:value={username} />
-	<Field.Description>Choose a unique username.</Field.Description>
-	<Field.Error>Username is already taken.</Field.Error>
-</Field.Root>
-```
-
-### Table
-
-Parts: Root, Header, Body, Footer, Row, Head, Cell, Caption
-
-```svelte
-<Table.Root>
-	<Table.Caption>User list</Table.Caption>
-	<Table.Header>
-		<Table.Row>
-			<Table.Head>Name</Table.Head>
-			<Table.Head>Email</Table.Head>
-		</Table.Row>
-	</Table.Header>
-	<Table.Body>
-		{#each users as user (user.id)}
-			<Table.Row>
-				<Table.Cell>{user.name}</Table.Cell>
-				<Table.Cell>{user.email}</Table.Cell>
-			</Table.Row>
-		{/each}
-	</Table.Body>
-</Table.Root>
-```
-
-### Popover
-
-Parts: Root, Trigger, Content
-
-```svelte
-<Popover.Root>
-	<Popover.Trigger>
-		<Button variant="ghost">Info</Button>
-	</Popover.Trigger>
-	<Popover.Content>
-		<p>Additional details here.</p>
-	</Popover.Content>
-</Popover.Root>
-```
-
-### Combobox
-
-Parts: Root, Input, Content, Item, Empty
-
-```svelte
-<script>
-	let query = $state('');
-</script>
-
-<Combobox.Root bind:value={query}>
-	<Combobox.Input placeholder="Search..." />
-	<Combobox.Content>
-		<Combobox.Item value="apple" index={0}>Apple</Combobox.Item>
-		<Combobox.Item value="banana" index={1}>Banana</Combobox.Item>
-		<Combobox.Empty>No results found.</Combobox.Empty>
-	</Combobox.Content>
-</Combobox.Root>
-```
-
-## Common Mistakes
-
-### Using bare compound name
-
-```svelte
-<!-- Incorrect: bare name -->
-<Tabs>...</Tabs>
-<Select>...</Select>
-
-<!-- Correct: always .Root -->
-<Tabs.Root>...</Tabs.Root>
-<Select.Root>...</Select.Root>
-```
-
-### Orphaned parts without Root
-
-```svelte
-<!-- Incorrect: parts without their Root wrapper -->
-<Card.Header>Title</Card.Header>
-<Card.Content>Body</Card.Content>
-
-<!-- Correct: parts inside Root -->
-<Card.Root>
-	<Card.Header>Title</Card.Header>
-	<Card.Content>Body</Card.Content>
-</Card.Root>
-```
-
-### Mixing parts from different components
-
-```svelte
-<!-- Incorrect: Dialog.Header inside Drawer -->
-<Drawer.Root>
-	<Dialog.Header>Title</Dialog.Header>
-</Drawer.Root>
-
-<!-- Correct: use matching parts -->
-<Drawer.Root>
-	<Drawer.Header>Title</Drawer.Header>
-</Drawer.Root>
-```
-
-## Full Compound Component List
-
-Run `dryui info <name>` for any component's complete parts list. If MCP is available, `ask --scope component "<name>"` is equivalent:
-
-Accordion, AlertDialog, Breadcrumb, Card, Collapsible, ColorPicker, Combobox, CommandPalette, ContextMenu, DataGrid, DatePicker, Dialog, DragAndDrop, Drawer, DropdownMenu, EmptyState, Field, FileUpload, FloatButton, Pagination, Popover, RadioGroup, RichTextEditor, Select, Splitter, Stepper, Table, Tabs, TagsInput, Toast, ToggleGroup, Toolbar, Tooltip, Tour, Transfer

package/skills/dryui/rules/design-brief.md

@@ -1,59 +0,0 @@
-# Design Brief Pipeline
-
-Use this rule before building or materially changing a UI. It keeps intent, component contracts, and polish review in the same visible loop.
-
-## Pipeline
-
-1. **User brief** — capture the audience, primary job, product/domain, density, tone, constraints, and success criteria. Ask only for missing information that changes the implementation.
-2. **DESIGN.md identity** — read the project `DESIGN.md` if present. If the project lacks one and the UI has meaningful visual direction, draft the identity in the working notes or create the file when the user asks for durable design guidance. Google-style `DESIGN.md` is an optional supported format, not a dependency.
-3. **DryUI lookup/plan** — use `dryui info`, `dryui compose`, or MCP `ask` before selecting components or recipes. Plan around confirmed component contracts, accessibility, tokens, and grid layout.
-4. **make-interfaces-feel-better polish intent pass** — explicitly list the polish details that apply before implementation. This is a planning step, not hidden preference.
-5. **Implementation** — build with DryUI components, Svelte 5, scoped grid CSS, tokenized styling, and accessible composition.
-6. **Deterministic check** — run `dryui check [path]` or MCP `check` against edited files or the workspace.
-7. **Visual review** — run `dryui check --visual <url>` or MCP `check` with `visualUrl`. Name the user brief and the polish intent in the review prompt when possible.
-8. **Repair loop** — fix issues in priority order, then repeat deterministic check and visual review until the screen satisfies the brief.
-
-## Precedence
-
-When guidance conflicts, use this order:
-
-1. User intent and explicit 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 decisions.
-5. make-interfaces-feel-better polish rubric.
-
-## Brief Shape
-
-Keep the brief short and implementation-oriented:
-
-- Who is using this?
-- What are they trying to do?
-- What information or action must be visible first?
-- How dense should the interface be?
-- What brand, product, or domain cues should shape the identity?
-- What constraints are fixed by the user, existing code, or platform?
-
-## DESIGN.md Identity
-
-Use `DESIGN.md` to preserve durable identity decisions: product personality, visual tone, density, navigation model, content hierarchy, color/token direction, motion posture, and examples of what to avoid.
-
-Do not treat `DESIGN.md` as more important than the user's current request. If the user changes direction, follow the user and update the identity only when the change is meant to persist.
-
-## Polish Intent
-
-The make-interfaces-feel-better pass should be explicit in planning and visual review. Check the applicable details:
-
-- balanced headings and pretty body wrapping
-- concentric radius for nested surfaces
-- icon swaps that crossfade without jitter
-- tabular numbers for counters, prices, clocks, and scores
-- transitions for interactive state, not keyframe-only state changes
-- staggered entrances when groups appear
-- smaller exits than entrances
-- shadow treatment for raised surfaces
-- optical icon alignment inside buttons
-- adaptive image edges for media and avatars
-- token consistency across color, radius, shadow, spacing, duration, and easing
-
-If a detail does not apply, skip it deliberately. Polish is a review rubric, not decoration.

package/skills/dryui/rules/design.md

@@ -1,71 +0,0 @@
-# Clean Code Standards
-
-## Core Principle
-
-Write the minimum correct code. Every line must earn its place.
-
-## Rules
-
-### No Premature Abstraction
-
-- Three similar lines > one premature helper
-- Only extract when you have 3+ real call sites
-- No "just in case" configurability, feature flags, or extension points
-- Delete code you don't need -- don't comment it out
-
-### No Noise
-
-- No comments that restate what code does
-- Comments only where the _why_ is non-obvious
-- No empty catch blocks -- handle or rethrow
-- No unused imports, variables, or parameters
-- No `console.log` left in production code
-- No commented-out code -- use git history
-
-### Names Are Documentation
-
-- Functions: verb + noun (`getUser`, `handleClick`, `parseDate`)
-- Booleans: `is`/`has`/`should` prefix (`isOpen`, `hasError`)
-- Collections: plural (`users`, `items`)
-- Callbacks: `on` + event (`onClose`, `onChange`)
-- Constants: UPPER_SNAKE only for true compile-time constants
-
-### Functions
-
-- One job per function
-- Max 3 parameters -- use an options object for more
-- Return early to avoid nesting
-- Pure functions where possible -- side effects at the edges
-
-### Error Handling
-
-- Only validate at system boundaries (user input, API responses, file reads)
-- Trust internal code -- don't null-check values you just created
-- Use specific error types, not generic strings
-- Handle errors at the level that can meaningfully respond
-
-### File Organization
-
-- One concept per file
-- Keep files under 300 lines -- split if growing
-- Colocate related code (component + styles + tests in same directory)
-- Index files only for re-exports, never for logic
-
-## Anti-Patterns -- Stop and Fix
-
-| If you're about to...                   | Instead...                                                   |
-| --------------------------------------- | ------------------------------------------------------------ |
-| Add a "utils" file                      | Put it where it's used (shared module only at 3+ call sites) |
-| Create a base class                     | Use composition                                              |
-| Add a config option nobody asked for    | Don't                                                        |
-| Write a comment explaining _what_       | Rename so it's obvious                                       |
-| Add error handling for impossible cases | Trust internal code                                          |
-| Create a wrapper around a simple API    | Use the API directly                                         |
-
-## 5 Rules of Programming
-
-1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places.
-2. Measure. Don't tune for speed until you've measured.
-3. Fancy algorithms are slow when n is small, and n is usually small.
-4. Fancy algorithms are buggier than simple ones. Use simple algorithms and simple data structures.
-5. Data dominates. If you've chosen the right data structures, the algorithms will be self-evident.

package/skills/dryui/rules/native-web-transitions.md

@@ -1,99 +0,0 @@
-# Native Web Transitions
-
-Use this skill when a UI should animate with platform APIs first, not JS animation libraries.
-
-## Default approach
-
-1. Start from a fully functional no-animation version.
-2. Add JS feature detection for `document.startViewTransition` before calling it.
-3. Gate transition-specific CSS with `@supports (view-transition-name: foo)`.
-4. Gate scroll-driven CSS with `@supports (animation-timeline: view())`.
-5. Add `prefers-reduced-motion` handling that removes typewriter, transition, and scroll-linked animation.
-6. Keep fallback behavior immediate and complete rather than approximating the effect with extra JS.
-
-## View Transition pattern
-
-Use when DOM changes should animate as a single state change.
-
-```ts
-function runWithViewTransition(update: () => void) {
-	if (!document.startViewTransition) {
-		update();
-		return Promise.resolve();
-	}
-
-	const transition = document.startViewTransition(update);
-	return transition.finished.catch(() => {});
-}
-```
-
-Use stable names only on the elements that should animate:
-
-```css
-@supports (view-transition-name: foo) {
-	.message {
-		view-transition-name: var(--vt-name);
-	}
-
-	::view-transition-new(message-enter) {
-		animation: dry-slide-up 240ms ease-out;
-	}
-}
-```
-
-Notes:
-
-- Assign unique `view-transition-name` values per inserted item.
-- Keep transitions short; they should clarify state changes, not delay interaction.
-- Trigger follow-up work such as `scrollIntoView` after `transition.finished`.
-
-## Scroll-driven reveal pattern
-
-Use for footer or section entry reveals tied to viewport position.
-
-```css
-@supports (animation-timeline: view()) {
-	.reveal {
-		animation: dry-fade-up linear both;
-		animation-timeline: view();
-		animation-range: entry 15% cover 35%;
-	}
-}
-```
-
-Fallback: leave the section fully visible with no animation.
-
-## Reduced motion
-
-Always include a reduced-motion override:
-
-```css
-@media (prefers-reduced-motion: reduce) {
-	.typing-dot,
-	.reveal {
-		animation: none;
-	}
-
-	:root {
-		scroll-behavior: auto;
-	}
-}
-```
-
-The `@media` block comes after the default rule in the same scoped stylesheet, so equal specificity plus source order handles the override without `!important` — which is banned by `@dryui/lint` (`dryui/no-important`). In JS, skip delayed typewriter/replay steps and render the final state immediately when reduced motion is active.
-
-## Svelte notes
-
-- Keep DOM mutation orchestration in the component that owns the rendered list.
-- Use `$effect` or `onMount` for browser-only APIs.
-- Do not access `document` or `window` during SSR; guard with `browser` or call inside browser-only lifecycle.
-- Prefer state-driven rendering and wrap only the mutation boundary in `startViewTransition`.
-
-## Checklist
-
-- Feature-detected `document.startViewTransition`
-- `@supports` around transition CSS
-- `@supports` around `animation-timeline`
-- `prefers-reduced-motion` disables motion and delay
-- Fallback path is functional without animation
-- No dependency on third-party animation runtime