skills/design-engineering/SKILL.md
Apply interface craft when building or reviewing UI - motion, easing, timing, springs, component feel, and visual foundations. Use when building a component, animation, transition, hover or press state, modal, drawer, toast, or when polishing an interface so it feels right. Says "make this feel better", "add an animation", "polish the UI", "review this component".
npx skillsauth add rohitg00/pro-workflow design-engineeringInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
In a world where most software works well enough, feel is the differentiator. Most of what makes an interface feel right is detail the user never consciously notices - the aggregate of small correct choices. Build for that aggregate.
Answer these in order before writing any animation.
The deciding factor is frequency. The more often a user sees it, the less it should move.
| How often the user sees it | Decision | |----------------------------|----------| | 100+ times/day (shortcuts, command palette) | No animation, ever | | Tens of times/day (hover, list nav) | Remove or drastically reduce | | Occasional (modals, drawers, toasts) | Standard animation | | Rare or first-time (onboarding, celebration) | Room for delight |
Never animate a keyboard-initiated action. It repeats all day; animation makes it feel slow and disconnected from the keypress.
Every animation needs an answer to "why does this move?" Valid ones: spatial consistency (enters and exits the same edge), state change, feedback (a press that confirms the interface heard you), or preventing a jarring appear/disappear. "It looks cool" is not a purpose for anything the user sees often.
ease-out (fast start, feels responsive).ease-in-out.ease.linear.Never use ease-in for UI. It delays the first moment of movement - exactly
when the user is watching - so a 300ms ease-in dropdown feels slower than a
300ms ease-out one. The built-in curves are weak; use stronger custom ones:
--ease-out: cubic-bezier(0.23, 1, 0.32, 1); /* UI interactions */
--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 */
| Element | Duration | |---------|----------| | Button press feedback | 100-160ms | | Tooltip, small popover | 125-200ms | | Dropdown, select | 150-250ms | | Modal, drawer | 200-500ms |
Keep frequent, interactive UI under 300ms; the modal and drawer range above (up to 500ms) is the deliberate exception for occasional, first-time surfaces. Perceived speed is real: a faster spinner makes a load feel faster at the same load time, and an instant tooltip after the first one makes a whole toolbar feel quick.
Springs settle on physics, not a fixed duration, so they feel alive and, unlike CSS keyframes, keep their velocity when interrupted. Reach for them on drag and gesture interactions the user can reverse mid-motion, and on decorative, mouse-tracked motion. Keep bounce subtle (0.1 to 0.3) and usually absent - save it for drag-to-dismiss and playful moments, not functional UI.
transform: scale(0.97) on
:active with a ~160ms ease-out transition. Subtle (0.95 to 0.98); it makes
the interface feel like it is listening.scale(0). Nothing real appears from nothing. Start at
scale(0.9) or higher plus opacity so the entrance has shape.prefers-reduced-motion. Drop or shorten non-essential motion.When reviewing UI code, output a single markdown table, one row per issue, with
Before | After | Why. Do not use separate "Before:" / "After:" lines.
| Before | After | Why |
|--------|-------|-----|
| transition: all 300ms | transition: transform 200ms ease-out | Name exact properties; avoid all |
| transform: scale(0) | scale(0.95); opacity: 0 | Nothing appears from nothing |
| ease-in on a dropdown | strong ease-out | ease-in reads as sluggish |
| no :active state | scale(0.97) on :active | Presses must feel responsive |
documentation
Apply clear-writing standards to any prose the agent produces - READMEs, docs, UI copy, error messages, commit and PR text, release notes. Use when writing or editing documentation, interface copy, or any text a human will read. Says "write the README", "improve this copy", "draft the docs", "word this error".
development
Drive a change through a red-green-refactor loop - failing test first, minimal code to pass, then clean up. Use when implementing a feature or fixing a bug where correctness matters and a test can pin the behavior. Says "TDD", "test first", "red green refactor", "write the test first".
tools
The index of every pro-workflow skill and command, grouped by job, with when to reach for each and whether it is human-run or auto-triggered. Use when you are not sure which skill fits, want the full map, or ask "what can this do", "which skill for X", "list the workflow".
development
Audit an area of the codebase and propose the smallest structural moves that improve it - untangle boundaries, kill duplication, fix seams, break cycles. Produces a prioritized plan and decision records, not a rewrite. Use when a codebase feels tangled, hard to change, or is becoming a ball of mud, or when asked to improve or refactor architecture.