@dryui/ui 2.0.0 → 2.0.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dryui/ui",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "Zero-dependency styled Svelte 5 components with scoped styles and --dry-* CSS variable theming.",
   "author": "Rob Balfre",
   "license": "MIT",
@@ -817,7 +817,7 @@
     "check:publish-hygiene": "bun run check:publint && bun run check:attw"
   },
   "dependencies": {
-    "@dryui/primitives": "^2.0.0"
+    "@dryui/primitives": "^2.0.1"
   },
   "peerDependencies": {
     "svelte": "^5.55.4"

package/skills/dryui/SKILL.md

@@ -228,7 +228,7 @@ Use these to look up APIs, discover components, plan setup, and validate code.
 
 1. `dryui info <Component>` or `dryui compose "<query>"` before writing so you confirm kind, required parts, bindables, and canonical usage. If MCP is available, `ask --scope component` and `ask --scope recipe` are the equivalent surface.
 2. Build the route or component with raw CSS grid, `Container` for constrained width, and `@container` for responsive layout.
-3. Run `check` if DryUI MCP is available after implementation to catch composition drift, layout violations, and accessibility regressions. Without MCP, rely on the `@dryui/lint` preprocessor plus the project's normal build and test commands.
+3. Run `dryui check [path]` or MCP `check` after implementation to catch composition drift, layout violations, and accessibility regressions. Use `dryui check --visual <url>` or MCP `check` with `visualUrl` when rendered pixels need review.
 4. Never guess component shape from memory. DryUI is intentionally strict, and the lookup cost is lower than rework.
 
 ### CLI (default entry point)
@@ -243,6 +243,8 @@ 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
@@ -260,6 +262,7 @@ Without a global install, prefix any command with `bunx @dryui/cli …` or `npx
 | 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
 

package/skills/dryui/rules/composition.md

@@ -457,7 +457,7 @@ DryUI is a presentation and accessibility system, not a workflow engine. For dep
 - Normalize route/session state in script before rendering DryUI inputs.
 - Reset dependent `Select.Root` values when their parent choice changes; do not rely on stale child state surviving domain changes.
 - Use raw CSS grid to lay out planner sections, and keep orchestration logic in route-level stores or derived state.
-- Run `dryui info <Component>` or `dryui compose "<pattern>"` before introducing a new field shape, then use MCP `check` if it is available after the flow is wired. Without MCP, rely on the `@dryui/lint` preprocessor plus the project's normal build and test commands.
+- Run `dryui info <Component>` or `dryui compose "<pattern>"` before introducing a new field shape, then run `dryui check [path]` or MCP `check` after the flow is wired. Use `dryui check --visual <url>` or MCP `check` with `visualUrl` when the rendered page needs visual review.
 
 ```svelte
 <script lang="ts">

package/skills/dryui/rules/theming.md

@@ -288,10 +288,10 @@ Ensure sufficient contrast between text and background.
 
 ## Validating Theme CSS
 
-Use `check <theme.css>` when DryUI MCP is available to catch theme issues. Without MCP, validate by rebuilding the app with `@dryui/lint` wired and checking the resulting diagnostics:
+Use `dryui check <theme.css>` or MCP `check <theme.css>` to catch theme issues. Without either surface, validate by rebuilding the app with `@dryui/lint` wired and checking the resulting diagnostics:
 
 ```bash
-check src/styles/global.css
+dryui check src/styles/global.css
 ```
 
 Common diagnostic codes: