Skip to content
Development
Skill

/design-engineering

UI craftsmanship: animation rules, easing, micro-interactions, state polish. Triggers: animation, transition, ease-out, motion, micro-interaction, hover, loading state, UI polish.

From plugin
ai-toolkit
161111 skills44 agents
Install
$ npx -y skills add softspark/ai-toolkit --skill design-engineering --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/design-engineering

Context preview

The summary Claude sees to decide when to auto-load this skill.

UI craftsmanship: animation rules, easing, micro-interactions, state polish. Triggers: animation, transition, ease-out, motion, micro-interaction, hover, loading state, UI polish.

SKILL.md

design-engineering.SKILL.md
name: design-engineering
description: "UI craftsmanship: animation rules, easing, micro-interactions, state polish. Triggers: animation, transition, ease-out, motion, micro-interaction, hover, loading state, UI polish."
effort: medium
user-invocable: false
allowed-tools: Read

Design Engineering Skill

Based on Emil Kowalski's design engineering philosophy — UI polish, component craftsmanship, and the compound value of invisible details.

Core Principles

  • **Taste is trainable.** Develops through studying exceptional work, reverse-engineering animations, and intentional practice.
  • **Invisible details create love.** Most UI refinements users never consciously register — but combined they produce something stunning.
  • **Beauty differentiates.** When functionality is table stakes, aesthetic excellence becomes genuine leverage.

Anti-Slop Visual Checklist

Defaults that signal machine-generated UI. Each is a falsifiable thing to avoid:

  • **Avoid** full-bleed saturated gradient backgrounds (purple-to-pink hero washes). A flat surface or a near-flat tonal shift reads as intentional; a loud gradient reads as a template.
  • **Avoid** emoji as load-bearing decoration — emoji standing in for icons, bullet markers, or section badges. Use a real icon set or typographic hierarchy instead.
  • **Avoid** the rounded-card-with-left-accent-border cliche repeated across every block. If three sections share that exact treatment, vary the layout or drop the accent.
  • **Avoid** hand-drawn fake imagery in SVG (synthetic "photos", invented logos, faux screenshots). Use a real asset or an honest labeled placeholder.
  • **Avoid** the overused default font stack (Inter/Roboto on system-ui for everything with no scale or weight intent). Pick type with a reason and lift the actual stack from source when one exists.

Minimum-Scale Floors

Accessibility-grounded hard thresholds. Going below these is a defect, not a style choice:

| Context | Floor | Basis | |---|---|---| | Slide / presentation body text | ~24px | Readable from the back of a room | | Print body text | ~12pt | Legible at arm's length on paper | | Mobile touch targets | 44px × 44px | Apple HIG minimum tappable size |

Treat these as the lower bound, not the target. Captions and footnotes may approach the floor; primary content should sit comfortably above it.

Context-First Discipline

High-fidelity work MUST be rooted in real context before any pixels are produced. This mirrors the toolkit's verify-don't-recall ethos:

  • **Read the source first.** Inspect the codebase, design tokens, UI kit, and screenshots that already exist before generating anything.
  • **Lift exact values.** Copy real hex codes, the spacing scale, the font stack, and radii straight from source. Do NOT reconstruct token values from memory — recalled values drift.
  • **Mock from scratch only as a last resort.** Building a screen with no reference is the fallback when no codebase, kit, or screenshot exists, not the default.

Question-Budget Gate

Calibrate questions to how bounded the ask is, then proceed:

  • **Rich context + bounded ask** → ask nothing, build. Example: "match this card to the existing dashboard" with the repo in hand.
  • **Open ask** → ask before building. Example: "prototype my onboarding" needs goals, target audience, and which dimension to diverge on (UX flow vs. visual treatment vs. copy). Resolve those three, then start.

Explore Many Variations

For exploratory or open work, produce **3+ atomic variations** across distinct axes, never three tweaks of one idea:

  • Vary on different dimensions: layout, color, type treatment, interaction model.
  • Deliberately mix safe matches with at least one novel direction — do not converge early.
  • Order them basic → advanced so the reviewer can scan the gradient (the "Design It Twice" premise extended past two).

Match Existing Vocabulary

When editing a live UI, conform to it instead of imposing a new style:

  • Reverse-engineer the palette, interactive states (hover/active/disabled), motion timing, and shadow/card/density treatment.
  • Match the copy tone too — terse product UI and chatty marketing copy are different vocabularies.
  • A change that introduces a foreign style is a regression even when it looks good in isolation.

No-Filler Content

  • **Every element earns its place.** No dummy stats, decorative sections, or lorem blocks added just to fill space. If a block has no purpose, cut it.
  • **Honest placeholder beats a bad fake.** A labeled placeholder ("[product screenshot]") is better than an invented icon or hand-drawn fake image. Do NOT fabricate assets — ask for the real ones.

Animation Decision Framework

Frequency determines approach

| Usage Pattern | Strategy | |---|---| | 100+ daily | No animation | | Tens daily | Drastically reduce | | Occasional | Standard animation | | Rare/first-time | Add delight |

**Never animate keyboard-initiated actions** — they repeat hundreds of times daily, making animation feel sluggish.

Purpose validation

Every animation requires justification: spatial consistency, state indication, explanation, user feedback, or preventing jarring transitions. "It looks cool" alone disqualifies frequent interactions.

Easing rules

| Direction | Easing | Why | |---|---|---| | Entering elements | `ease-out` | Immediate feedback | | On-screen movement | `ease-in-out` | Natural acceleration | | Hover/color changes | `ease` | Smooth transition | | Constant motion | `linear` | No acceleration |

**Critical:** Abandon default CSS easings. Use custom curves:

/* Punchy entrance */
transition-timing-function: cubic-bezier(0.23, 1, 0.32, 1);

**Never use `ease-in`** — it delays initial movement exactly when attention peaks, making interfaces feel sluggish.

Duration guidelines

| Element | Timing | |---|---| | Button press | 100-160ms | | Tooltips, small popovers | 125-200ms | | Dropdowns, selects | 150-250ms | | Modals, drawers | 200-500ms |

Read more
Ships withai-toolkit

Professional-grade AI coding toolkit with multi-platform support. Machine-enforced safety, 109 skills, 44 agents, expanded lifecycle hooks, persona presets, experimental opt-in plugin packs, and benchmark tooling — works with Claude Code, Claude Chat/Cowork,

Get the whole plugin