agents/skills/emil-design-engineering/SKILL.md
Design engineering principles and patterns for building polished, accessible web interfaces. Use when building UI components, reviewing frontend code, implementing forms, handling touch interactions, optimizing performance, or creating marketing pages. Triggers on UI polish, input/form validation, button states, mobile UX, accessibility/a11y, keyboard navigation, typography, layout shift, animations/transitions, hover and tap targets, iOS Safari, prefers-reduced-motion, dark mode, and landing pages.
npx skillsauth add carterdea/dots emil-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.
A comprehensive guide for building polished, accessible web interfaces based on Emil Kowalski's design engineering practices.
| Category | When to Use | | ----------------------------------------------- | ---------------------------------------------------- | | Animations | Enter/exit transitions, easing, springs, performance | | UI Polish | Typography, visual design, layout, colors | | Forms & Controls | Inputs, buttons, form submission | | Touch & Accessibility | Mobile, touch devices, keyboard nav, a11y | | Component Design | Compound components, composition, props API | | Marketing | Landing pages, blogs, docs sites | | Performance | Virtualization, preloading, optimization | | Design Rules | Paired right/wrong calls across icons, type, color, IA, interaction, copy |
Dynamic elements should cause no layout shift. Use hardcoded dimensions, font-variant-numeric: tabular-nums for changing numbers, and avoid font weight changes on hover/selected states.
Design for touch first, then add hover enhancements. Disable hover effects on touch devices. Ensure 44px minimum tap targets. Never rely on hover for core functionality.
Tabbing should work consistently. Only allow tabbing through visible elements. Ensure keyboard navigation scrolls elements into view with scrollIntoView().
Every animation needs prefers-reduced-motion support. Every icon button needs an aria label. Every interactive element needs proper focus states.
Product UI should be fast and purposeful. Skip animations for frequently-used interactions. Marketing pages can be more elaborate.
Will users see this 100+ times daily?
├── Yes → Don't animate
└── No
├── Is this user-initiated?
│ └── Yes → Animate with ease-out (150-250ms)
└── Is this a page transition?
└── Yes → Animate (300-400ms max)
Is the element entering or exiting?
├── Yes → ease-out
└── No
├── Is it moving on screen?
│ └── Yes → ease-in-out
└── Is it a hover/color change?
├── Yes → ease
└── Default → ease-out
| Mistake | Fix |
| --------------------------- | ------------------------------------------- |
| transition: all | Specify exact properties |
| Hover effects on touch | Use @media (hover: hover) |
| Font weight change on hover | Use consistent weights |
| Animating height/width | Use transform and opacity only |
| No reduced motion support | Add prefers-reduced-motion query |
| z-index: 9999 | Use fixed scale or isolation: isolate |
| Custom page scrollbars | Only customize scrollbars in small elements |
When reviewing UI code, check:
transition: allFor detailed guidance on specific topics:
development
Add net-new product, workflow, platform, or developer-experience features as small vertical slices. Use this skill whenever the user asks to build a new feature, add a new page/route/API/workflow/job/eval/operator path, enrich an existing feature with a new user-visible capability, or plan feature architecture before coding. This skill maps the files to change or create, defines the authoritative contract, specifies tests, and gives a QA plan before treating the feature as done.
development
Verify a developer's finished Trello ticket on a non-Shopify web app and render a verdict. Dogfood the posted preview (desktop + mobile) against the card's acceptance criteria, then PASS it (approve the PR, move to Ready for Release) or FAIL it (request changes, attach repro, reassign the dev, move to Development). Read-only: never implements, commits, or opens a PR. Use when asked to 'QA this card', 'test before release', or 'sign off on this ticket'. Shopify themes use shopify-trello-qa; building a ticket uses trello-delivery.
development
Verify a developer's finished Shopify theme ticket and render a verdict. Dogfood the posted preview theme and Customizer (desktop + mobile) against the card's acceptance criteria and Figma, then PASS it (approve the PR, move to Ready for Release) or FAIL it (request changes, attach repro, reassign the dev, move to Development). Read-only: never implements, commits, deploys, or opens a PR. Use when asked to 'QA this Shopify card', 'verify the Ready for Testing card', or 'sign off on this theme ticket'. Non-Shopify apps use trello-qa; building a ticket uses shopify-trello-delivery.
development
Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.