菜单
Use when designing, building, reviewing, or polishing user interfaces, motion, component behavior, interaction details, and product-feel across any frontend stack. Generalized from Emil Kowalski-style design engineering principles; framework-neutral, implementation-first.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Drive a subject to convergence by repeatedly completing its critique-generated Dex epic, re-running the same critique, and reporting what changed — until it's clean or hits a stop condition. Use when asked to "loop the critique", "keep fixing until clean", "re-critique after the fixes", "iterate on the design/UX until it converges", "complete the epic then re-run the critic", or "run the critique loop". Works with any critique that emits the shared report contract (ui-design-critique, ux-critique, …).
Design critique for user interfaces that produces a prioritized, strict report of design issues. Use when asked to "critique this design", "review the UI", "design review", "roast my UI", "is this AI slop", "does this look AI-generated", "audit the visual design", or evaluate a screen, page, or screenshot against brand guidelines or a DESIGN.md spec. Classifies every finding as a gap, inconsistency, suggestion, or strength and ranks it by impact. Runs deterministic DOM detectors to catch broken layout (overflow, overlap, clipping) and evaluates visually via browser/devtools capture and against design tokens.
Convert a prioritized critique or findings report into a Dex epic with tasks. Use when asked to "turn this critique into tasks", "make a dex epic from these findings", "create tasks from the design review", "add these to dex", or "backlog this critique". Works with any prioritized findings list — including the ui-design-critique report — by normalizing to a common contract, then creating a Dex epic with priority-ranked, well-contextualized tasks.
Interview the user to create a unique DESIGN.md that defines an app's look. Use when asked to "grill me for a design.md", "create a design spec", "define the app's look", "make a DESIGN.md", "build a brand/design system doc", or "interview me for a visual identity". Grills one question at a time toward a committed, non-generic identity, then authors a valid DESIGN.md (tokens + prose) and lints it. Actively steers away from AI-slop defaults.
Interview the user to define who an app's users actually are. Use when asked to "define our users", "identify the users", "who is this for", "create user personas", "make a USERS.md", "define the target audience", or "what user types do we have". Grills one question at a time to produce a USERS.md — multiple distinct user types with their goals, context, proficiency, motivations, frustrations, and the cues that make each feel "this is for me".
UX critique for interfaces and flows that produces a prioritized, strict report of experience issues. Use when asked to "critique the UX", "UX review", "usability review", "heuristic evaluation", "why is this flow confusing", "is this hard to use", "find friction", or evaluate whether a user can complete a task. Walks the actual flow, classifies every finding as a gap, inconsistency, suggestion, or strength, and ranks by impact on task success. Flags dark patterns. Shares the critique report contract with ui-design-critique so critique-to-dex ingests it directly.
基于 SOC 职业分类
| name | design-engineering |
| description | Use when designing, building, reviewing, or polishing user interfaces, motion, component behavior, interaction details, and product-feel across any frontend stack. Generalized from Emil Kowalski-style design engineering principles; framework-neutral, implementation-first. |
Use this skill to make interfaces feel intentional, fast, and physically believable — not merely functional. It is framework-neutral: apply it to HTML/CSS, Svelte, React, Vue, native apps, Web Components, canvas/WebGL, or design specs.
The goal is not decoration. The goal is product feel: the compounding effect of layout, motion, responsiveness, accessibility, and tiny interaction details that users rarely notice consciously but absolutely feel.
Use for:
Do not use for:
Good taste is not vibes. It is pattern recognition built by studying great interfaces, reverse-engineering why they feel good, inspecting tiny details, and practicing until the defaults become sharp.
Do not stop at “it works.” Ask what the user feels in the first 100ms after they act.
The best UI details disappear. A popover opens from the trigger. A button visibly responds to pressure. A list reorders without losing spatial continuity. A destructive action feels serious without feeling dramatic.
Users may not name these details, but their nervous system does.
Most software is good enough. Taste is a differentiator. Strong defaults, precise motion, and coherent interaction details make tools feel more trustworthy and more desirable.
When reviewing UI or code, prefer a compact table:
| Before | After | Why |
|---|---|---|
transition: all 300ms | transition: transform 180ms var(--ease-out), opacity 180ms var(--ease-out) | Exact properties avoid accidental slow/janky animations |
Element appears from scale(0) | Start at scale(.96) + opacity: 0 | Real objects do not appear from mathematical nothing |
| Popover scales from center | Popover scales from trigger edge/origin | Motion should explain where the surface came from |
| Keyboard command opens animated palette | Keyboard command opens instantly | Frequent keyboard actions must feel immediate |
If making changes, also report:
Ask how often the user sees it.
| Frequency | Decision |
|---|---|
| Hundreds of times/day: command palette, keyboard nav, shortcut-driven actions | No animation, or effectively instant |
| Tens of times/day: hover, row focus, common navigation | Minimal feedback only |
| Occasional: dialogs, drawers, toasts, settings panels | Standard motion is useful |
| Rare: onboarding, empty-state celebration, marketing demo | Delight is allowed |
Rule: keyboard-initiated actions should generally not animate. Keyboard users are asking for speed.
Valid purposes:
If the purpose is only “looks cool,” cut it unless the moment is rare and intentionally expressive.
Default decisions:
ease-outease-in-outease or tokenized curvelinearUseful CSS curves:
:root {
--ease-out: cubic-bezier(0.23, 1, 0.32, 1);
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);
}
Avoid ease-in for most UI entrances. It withholds motion at the moment the user is watching, so it feels sluggish.
| Interaction | Duration |
|---|---|
| Press feedback | 80–160ms |
| Hover/focus feedback | 100–180ms |
| Tooltip | 100–160ms, often no delay after first hover |
| Popover/menu | 140–220ms |
| Toast enter | 180–260ms |
| Dialog/drawer | 200–320ms |
| Page/route transition | 200–400ms, only if it preserves orientation |
| Exit of temporary UI | Usually faster than enter |
Perceived performance matters more than raw duration. The first visual response should happen immediately, even if the full transition takes longer.
allBad:
.card { transition: all 300ms ease; }
Good:
.card {
transition:
transform 180ms var(--ease-out),
opacity 180ms var(--ease-out),
border-color 140ms ease;
}
Animate transform and opacity by default. Treat layout properties (height, width, top, left, margin) as expensive and suspicious unless the element count is small and you have tested it.
If animating layout is necessary, isolate the damage:
scale(0)Bad:
.popover[data-state='open'] { transform: scale(1); }
.popover[data-state='closed'] { transform: scale(0); }
Good:
.popover {
transform-origin: var(--surface-origin, top center);
transition: transform 160ms var(--ease-out), opacity 120ms ease;
}
.popover[data-state='closed'] {
transform: scale(.96) translateY(-2px);
opacity: 0;
}
Objects should feel like they enter the world, not spawn from zero dimension.
Buttons and pressable controls need a visible response.
Good patterns:
.button {
transition: transform 120ms var(--ease-out), background-color 120ms ease;
}
.button:active {
transform: scale(.97);
}
For dense professional tools, reduce the scale change: .99 or a color/brightness response can be enough.
Users change their mind mid-transition. UI should survive interruption.
Prefer:
Avoid brittle keyframe choreography for basic UI state changes.
@starting-style for enter transitions when supportedFor native CSS enter animations without mounting hacks:
.panel {
opacity: 1;
transform: translateY(0);
transition: opacity 160ms ease, transform 160ms var(--ease-out);
@starting-style {
opacity: 0;
transform: translateY(4px);
}
}
Use progressive enhancement. Do not make the component depend on unsupported behavior without a fallback.
A polished component defines:
A component that only defines colors and border radius is not done.
Prefer component props/options that encode product intent over raw styling knobs.
Better:
variant: 'primary' | 'secondary' | 'danger'
density: 'comfortable' | 'compact'
emphasis: 'strong' | 'subtle'
Worse:
borderColor: string
paddingX: number
animationDuration: number
Expose escape hatches only when real use cases demand them.
Do not bolt them on later. A component should know how it behaves when:
Keyboard focus should be visible, tasteful, and predictable. Never remove outlines without replacing them. Focus movement must match user intent.
Checklist:
Use a combination of distance and velocity. A quick confident flick should dismiss even if distance is short; a slow accidental drag should recover.
When dragging past a limit, apply resistance/friction instead of hard stopping. Hard stops feel cheap and broken.
For web drag interactions, use pointer events and pointer capture so dragging remains coherent even if the pointer leaves the element.
function onPointerDown(event: PointerEvent): void {
event.currentTarget.setPointerCapture(event.pointerId);
}
Guard multi-touch if the gesture is single-pointer.
On release, animate to the nearest intentional state: closed, open, dismissed, snapped, reordered. Do not leave fractional awkward states unless the UI is truly continuous.
Before adding effects, fix:
If a screen feels confusing, do not add borders everywhere. Clarify hierarchy with grouping, spacing, type scale, and content order first.
A high-quality component should look good with minimal configuration. If every usage needs five props/classes to look acceptable, the abstraction is weak.
Check:
Implement prefers-reduced-motion. Reduced does not always mean zero; it means remove vestibular motion and long transitions.
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
scroll-behavior: auto !important;
}
.animated-surface {
transition-duration: 1ms;
animation-duration: 1ms;
}
}
Prefer component-scoped reductions when possible so you do not destroy useful non-motion affordances globally.
Do not hide essential actions behind hover. Hover effects should enhance, not reveal required functionality.
Use pointer/hover media queries when needed:
@media (hover: hover) and (pointer: fine) {
.card:hover { transform: translateY(-1px); }
}
A disabled button with no explanation is often bad UX. Prefer visible requirements, inline validation, or enabled actions that explain what is missing.
A transition can be technically cheap and still feel wrong. Test with real interaction speed, repeated use, and interruption.
For simple enter/exit/hover/press states, CSS transitions are smaller, interruptible, and resilient. Use JavaScript when animation depends on runtime measurement, gestures, sequencing, physics, or canvas/WebGL.
If using a JS animation library:
Animating a CSS custom property can invalidate more than expected because variables inherit. It can be fine; just test it in real DOM shape before assuming it is free.
Temporarily multiply durations by 4–10x. Bad origins, weird easing, cross-fades, and layout jumps become obvious.
Use browser/devtool animation inspection or screen recording scrub. Verify:
Repeatedly open/close, hover/unhover, drag/cancel, route away, resize, and spam-click. Polished UI survives rude users.
Before calling UI done, test:
ease-inBefore shipping UI, answer yes:
If any answer is no, fix it before calling the interface polished.
This skill is generalized from Emil Kowalski-style design engineering principles and the source skill Scott provided, with framework-specific React/Framer assumptions removed. Keep the craft, lose the framework lock-in.