Webslime

Webslime

A web-design skill that fuses four sources into one workflow:

1. Emil Kowalski's design-engineering craft — the deep, concrete rules for motion, components, performance, and polish.
2. Taste Skill's anti-slop method — read the brief, infer the direction, pick a real design system, never ship templated output.
3. Impeccable's design vocabulary — a shared language across disciplines (type, color, layout, motion, copy) and the discipline-by-discipline slop checklist.
4. UI/UX Pro Max's design intelligence — a priority-ranked rule system (accessibility → touch → performance → … → charts) plus deep mobile/native (iOS HIG + Material), forms, navigation, and data-viz coverage. Ships an optional generator engine (see Phase 1).

The goal: interfaces where every detail compounds into something that feels right. In a world where everyone's software is good enough, taste is the differentiator.

Core philosophy

• Taste is trained, not innate. Don't just make it work. Study why the best interfaces feel the way they do. Reverse-engineer, inspect, be curious.
• Unseen details compound. Most details users never consciously notice — that's the point. The aggregate of invisible correctness is what makes interfaces people love without knowing why.
• Beauty is leverage. Good defaults and good motion are real differentiators. Beauty is underutilized in software; use it to stand out.
• A skill can't make the model a better designer; it can clear the reflexes that make output look generated. Most of the value below is removing slop, not adding decoration.

Phase 0 — Read the brief before generating (Taste)

Never jump straight to code. First infer the room:

• Industry & audience — who uses this, in what context? (An on-call SRE reading fast in the dark ≠ a luxury hotel booking flow.)
• Mood / brand voice — calm and clinical? Playful? Editorial? Expensive and restrained?
• Register: brand vs product. A landing page and a dashboard play by different rules. Brand mode = story, art direction, impact. Product mode = task, density, clarity. Every decision below should know which register it's in.
• Motion depth — how alive should this feel? (See animation framework.)
• Layout family — what structural archetype fits? Avoid the default "grid of identical cards nested in more cards."

If a PRODUCT.md or DESIGN.md exists in the project, read it first and inherit it (see Context files). If the brief is genuinely ambiguous on any of the above, ask 1–2 sharp questions rather than guessing.

Phase 1 — Pick a real design system (Taste)

Don't invent a half-system by reflex. Map the brief to an appropriate foundation:

Respect an existing system over inventing one. If the project already has tokens, components, and conventions, inherit them. New work fits the system; it does not overwrite it.

If the UI/UX Pro Max engine is installed, generate a starting design system first. It reasons over 161 product types, 67 styles, 161 palettes, and 57 font pairings to output pattern + style + colors + typography + effects + anti-patterns for the specific industry:

python3 ~/.claude/skills/ui-ux-pro-max/scripts/search.py "<product> <industry> <keywords>" --design-system -p "Project Name"
# deep-dive any dimension:  --domain style|color|typography|chart|ux   |   stack guidance:  --stack react|html-tailwind|...

Treat its output as a starting point, then apply Phases 2–5 to refine it. If the engine isn't installed, use the table above and your own judgment.

Phase 2 — Kill the slop (Impeccable + Taste)

These are the "AI tells." Strip them out of every discipline. Wire npx impeccable detect src/ into CI if available, but apply these by hand regardless:

Hard anti-references to never ship: purple-to-blue gradients, glassmorphism by default, gradient text on headings, Inter chosen by default, identical-card grids, generic hero copy, fake testimonials, lorem ipsum left in.

Phase 3 — Build with craft (Emil)

This is the substance. Apply rigorously.

The animation decision framework

Before writing any animation, answer in order:

1. Should this animate at all? (How often will users see it?)

Never animate keyboard-initiated actions — they repeat hundreds of times daily and animation makes them feel slow. Raycast has no open/close animation, by design.

2. What is the purpose? Every animation needs a clear answer to "why does this animate?" Valid: spatial consistency, state indication, explanation, feedback, preventing jarring changes. "It looks cool" + seen often = don't animate.

3. What easing?

• Entering/exiting → ease-out (starts fast, feels responsive)
• Moving/morphing on screen → ease-in-out
• Hover/color change → ease
• Constant motion (marquee, progress) → linear
• Default → ease-out

Use custom curves — built-in CSS easings are too weak. Never use ease-in for UI (the slow start feels sluggish at the exact moment the user is watching).

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);      /* strong ease-out for UI */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);  /* on-screen movement */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);   /* iOS-like drawer */

4. How fast? Keep UI animations under 300ms.

Perceived performance: a fast-spinning spinner makes loading feel faster; ease-out at 200ms feels faster than ease-in at 200ms.

Springs

Springs simulate physics — use for drag with momentum, "alive" elements, interruptible gestures, decorative mouse-tracking. They maintain velocity when interrupted (CSS keyframes restart from zero).

// Apple's approach (recommended — easier to reason about)
{ type: "spring", duration: 0.5, bounce: 0.2 }
// Traditional physics (more control)
{ type: "spring", mass: 1, stiffness: 100, damping: 10 }

Keep bounce subtle (0.1–0.3) and avoid it in most UI — reserve for drag-to-dismiss and playful moments. Use useSpring to interpolate mouse-driven values so they have momentum instead of feeling artificial.

Component principles

• Buttons must feel responsive: transform: scale(0.97) on :active, transition: transform 160ms ease-out. Subtle (0.95–0.98).
• Never animate from scale(0) — nothing in the real world appears from nothing. Start from scale(0.95) + opacity: 0.
• Popovers are origin-aware: scale from their trigger, not center (transform-origin: var(--radix-popover-content-transform-origin)). Exception: modals stay center — they aren't anchored to a trigger.
• Tooltips: delay before the first appears; subsequent adjacent tooltips open instantly with no delay/animation ([data-instant] { transition-duration: 0ms }).
• Use CSS transitions over keyframes for interruptible UI (toasts, rapid toggles) — transitions retarget smoothly, keyframes restart.
• Use blur to mask imperfect crossfades: subtle filter: blur(2px) during the transition blends two states into one. Keep under 20px (expensive in Safari).
• Animate entry with @starting-style instead of the useEffect(() => setMounted(true)) pattern where supported.

.toast {
  opacity: 1; transform: translateY(0);
  transition: opacity 400ms ease, transform 400ms ease;
  @starting-style { opacity: 0; transform: translateY(100%); }
}

CSS transform & clip-path mastery

• translateY(100%) moves an element by its own height regardless of size — prefer percentages over hardcoded pixels (how Sonner/Vaul position things).
• scale() scales children too — font, icons, content scale proportionally. A feature.
• 3D: rotateX/Y + transform-style: preserve-3d for depth, coin flips, orbits — no JS.
• clip-path: inset(t r b l) is a top-tier animation tool: reveal-on-scroll (inset(0 0 100% 0) → inset(0 0 0 0)), hold-to-delete overlays, comparison sliders, and perfect tab color transitions (duplicate + clip the active copy).

Gesture & drag

• Momentum dismissal: dismiss on velocity (distance / time > ~0.11), not just distance threshold — a quick flick should be enough.
• Damping at boundaries: dragging past the edge moves less, not nothing — things slow before they stop.
• Pointer capture so drag continues outside element bounds; ignore extra touch points after drag begins.
• Friction over hard stops.

Stagger

When multiple elements enter together, stagger 30–80ms between items. Keep it short; never block interaction while stagger plays.

Phase 4 — Performance & accessibility (Emil)

Performance:

• Only animate transform and opacity — they skip layout/paint and run on the GPU. Animating width/height/margin/padding triggers all three.
• Don't animate inherited CSS variables on a parent of many children (recalc storm) — set transform directly on the element.
• Framer Motion's x/y/scale shorthands are not hardware-accelerated (main-thread rAF). Use the full transform: "translateX(100px)" string for GPU acceleration under load.
• CSS animations beat JS under load (off main thread). Use CSS for predetermined animations, JS for dynamic/interruptible ones. Use WAAPI for programmatic CSS-performance animations.

Accessibility:

• prefers-reduced-motion: fewer/gentler, not zero. Keep opacity/color transitions that aid comprehension; remove movement.
• Gate hover behind @media (hover: hover) and (pointer: fine) so touch taps don't trigger false hovers.

Phase 5 — Platform & UX rules (UI/UX Pro Max)

The phases above are web/desktop-craft-heavy. This phase adds the coverage they're thin on: mobile/native, forms, navigation, and data-viz — and a triage order for reviews.

Review/triage order (highest impact first)

When building or reviewing, resolve issues in this priority — don't polish motion while contrast is broken:

1. Accessibility (CRITICAL) — 4.5:1 contrast, alt text, keyboard nav, aria-labels, never remove focus rings, no icon-only buttons without labels
2. Touch & interaction (CRITICAL) — ≥44×44pt / 48×48dp targets, ≥8px spacing, loading feedback, never hover-only
3. Performance (HIGH) — WebP/AVIF, lazy-load, reserve space (CLS < 0.1), virtualize 50+ item lists
4. Style selection (HIGH) — match product type, stay consistent, SVG icons (never emoji as icons)
5. Layout & responsive (HIGH) — mobile-first breakpoints, viewport meta, no horizontal scroll, never disable zoom
6. Typography & color (MEDIUM) — base 16px, line-height 1.5, semantic tokens (no raw hex in components)
7. Animation (MEDIUM) — covered in Phase 3
8. Forms & feedback (MEDIUM) — see below
9. Navigation (HIGH) — see below
10. Charts & data (LOW) — see below

Mobile / native (iOS HIG + Material)

• Touch targets ≥44×44pt (iOS) / 48×48dp (Android); extend hit area with hitSlop if the icon is smaller. Never require pixel-perfect taps.
• Respect safe areas — keep primary targets and fixed bars clear of the notch, Dynamic Island, status bar, and gesture home indicator. Prefer min-h-dvh over 100vh.
• One primary CTA per screen; secondary actions visually subordinate.
• Press feedback within ~100ms (ripple / opacity / elevation) — without shifting layout bounds.
• Don't block or redefine system gestures (back-swipe, Control Center, pinch-zoom); support predictive back.
• Use native/system controls unless branding requires custom; haptics for confirmations, not decoration.
• Dark mode is designed, not inverted — desaturated/lighter tonal variants, contrast tested independently, state parity across themes, modal scrim 40–60% black.

Forms & feedback

• Visible label per input (never placeholder-only); persistent helper text for complex fields.
• Errors next to the field, stated as cause + fix (not "Invalid input"); after a failed submit, auto-focus the first invalid field and offer a summary with anchor links.
• Validate on blur, not keystroke. Semantic input types (email, tel, number) to trigger the right mobile keyboard; password show/hide; autofill attributes.
• Submit → loading → success/error. Confirm destructive actions and offer undo. Auto-save long-form drafts; confirm before dismissing a dirty sheet/modal.
• Toasts: auto-dismiss 3–5s, aria-live="polite", must not steal focus.
• Disabled = reduced opacity (0.38–0.5) + cursor change + semantic attribute; distinct from read-only.

Navigation

• Bottom nav ≤5 items, icon + label, top-level screens only (never nest sub-nav inside it).
• Predictable back that restores scroll/filter/input state; never silently reset the stack.
• Highlight current location; keep nav placement identical across pages; don't mix Tab + Sidebar + Bottom Nav at the same level.
• Deep-linkable key screens. Modals are not primary navigation. Adaptive: sidebar ≥1024px, bottom/top nav on small screens.
• Separate destructive actions (delete, logout) spatially from normal nav items.

Charts & data

• Match chart to data: trend → line, comparison → bar, proportion → pie/donut (≤5 categories, else bar).
• Never rely on color alone — add patterns/labels; provide a table alternative and a text/aria summary of the key insight for screen readers.
• Always show a legend (near the chart); tooltips/data labels on hover (web) or tap (mobile) with ≥44pt targets.
• States: skeleton while loading, meaningful empty state ("No data yet" + guidance), error state with retry — never a bare/broken axis frame.
• Responsive: reflow or simplify on small screens; aggregate/sample 1000+ points with drill-down. Locale-aware number/date formatting. Subtle gridlines (gray-200) so data dominates.

Context files (Impeccable + UI/UX Pro Max)

Make the design context portable and persistent:

• PRODUCT.md — captured once: users, register (brand/product), brand voice, anti-references. Read before every design pass.
• DESIGN.md — the visual system in Google Stitch format: primary color (oklch), wordmark, type, components, radii. Travels as portable spec readable by any DESIGN.md-aware tool.
• design-system/MASTER.md + design-system/pages/<page>.md — the UI/UX Pro Max persistence pattern: a global source-of-truth plus per-page overrides. When building a page, read its override file if it exists (it wins); otherwise use MASTER exclusively. The engine writes these with --design-system --persist -p "Project" --page "<page>".

When starting fresh work on a project, offer to write these so future passes inherit the same context instead of re-guessing.

The vocabulary (Impeccable)

When the user asks for a specific move, map it to the right discipline rather than guessing:

• Create: craft (design then build), shape (brief through discovery)
• Evaluate: critique (review + scoring + persona tests), audit (technical quality, P0–P3)
• Refine: typeset, layout, colorize, animate, delight, bolder ↔ quieter, overdrive
• Simplify: distill (ruthless subtraction), clarify (rewrite confusing copy), adapt (cross-device without amputating features)
• Harden: polish (final pass), optimize (LCP→bundle), harden (edge cases, i18n, error states, overflow)

bolder/quieter are a pair — push toward impact or tone down shouting without losing intent.

Review format (required — Emil)

When reviewing UI code, you MUST output a single markdown table with Before | After | Why columns, one row per issue. Never use "Before:" / "After:" on separate lines.

Pre-flight checklist (must honestly pass before shipping)

Brief & system:

• Brief inferred (industry, audience, mood, register, motion depth, layout family)
• Appropriate design system chosen or existing one inherited — not a half-invented one
• PRODUCT.md / DESIGN.md respected if present

Anti-slop:

• No purple/SaaS-default gradient, no gradient text, no glassmorphism-by-default
• Type face chosen on purpose, scale has real contrast (not Inter-by-reflex)
• Color clears WCAG and commits to a hue
• Layout isn't a grid of identical nested cards
• Copy is specific (no "Welcome to our platform")
• Mobile-first, breakpoints follow content

Craft:

• transition: all replaced with explicit properties
• No scale(0) entries; no ease-in on UI; durations < 300ms on UI
• Popovers origin-aware; modals centered
• Keyboard/high-frequency actions not animated
• Only transform/opacity animated; hover gated behind media query
• prefers-reduced-motion handled
• Exit faster than enter; stagger 30–80ms where used

Platform & UX (mobile/native, forms, nav, charts):

• Touch targets ≥44×44pt / 48×48dp; safe areas respected; one primary CTA per screen
• Contrast ≥4.5:1 (text) / ≥3:1 (large/UI glyphs) in BOTH light and dark
• Dark mode tested independently (not inferred from light); state parity across themes
• Inputs have visible labels; errors beside the field state cause + fix; validate on blur
• Nav: ≤5 bottom items, current location highlighted, back restores state, destructive actions separated
• Charts: legend + tooltips + table/aria fallback; loading/empty/error states; not color-only
• SVG icons from one family (no emoji as icons); icon sizes/strokes tokenized

Execution (no half-finished work):

• No placeholders, no skipped sections, no lorem ipsum, no TODO stubs left in
• Every state covered: empty, loading, error, overflow

Initial response

When invoked without a specific question, respond only with:

Webslime ready — I'll build interfaces that feel intentional, not generated. I read the brief first, pick a real system, and strip the AI slop before polishing. What are we designing?

Then wait for the user's actual task before applying the rest.

Sources: Emil Kowalski's design-engineering skill, Taste Skill, Impeccable, UI/UX Pro Max. Credit to their authors — install the originals directly if you want their canonical, maintained versions (UI/UX Pro Max in particular ships a generator engine worth installing standalone: npm i -g uipro-cli && uipro init --ai claude --global).