fluxly Search skills… ⌘K 中文 Sign in Publish

emil-design-engineering

Design Community

Repo stars 0
Author repo sea-prototype-template

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Design engineering principles and patterns for building polished, accessible web interfaces. Use this skill when building UI com…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Quick Reference”, “Core Principles”, “1. No Layout Shift”, “2. Touch-First, Hover-Enhanced”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name emil-design-engineering directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Quick Reference / Core Principles / 1. No Layout Shift” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Emil's Design Engineering Principles

A comprehensive guide for building polished, accessible web interfaces based on Emil Kowalski's design engineering practices.

Quick Reference

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

Core Principles

1. No Layout Shift

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.

2. Touch-First, Hover-Enhanced

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().

4. Accessibility by Default

Every animation needs prefers-reduced-motion support. Every icon button needs an aria label. Every interactive element needs proper focus states.

5. Speed Over Delight

Product UI should be fast and purposeful. Skip animations for frequently-used interactions. Marketing pages can be more elaborate.

Decision Flowcharts

Should I Animate This?

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)

What Easing Should I Use?

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

Common Mistakes

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

Review Checklist

When reviewing UI code, check:

No layout shift on dynamic content
Animations have reduced motion support
Touch targets are 44px minimum
Hover effects disabled on touch devices
Keyboard navigation works properly
Icon buttons have aria labels
Forms submit with Enter/Cmd+Enter
Inputs are 16px+ to prevent iOS zoom
No transition: all
z-index uses fixed scale

Reference Files

For detailed guidance on specific topics:

animations.md - Easing, timing, springs, performance
ui-polish.md - Typography, shadows, gradients, scrollbars
forms-controls.md - Inputs, buttons, form patterns
touch-accessibility.md - Touch devices, keyboard nav, a11y
component-design.md - Compound components, composition, props API
marketing.md - Landing pages, blogs, docs
performance.md - Virtualization, preloading, optimization

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Design
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @lemu · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview emil-design-engineering.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Emil's Design Engineering Principles

A comprehensive guide for building polished, accessible web interfaces based on Emil Kowalski's design engineering practices.

## Quick Reference

| Category | When to Use |
| --- | --- |
| [Animations](animations.md) | Enter/exit transitions, easing, springs, performance |
| [UI Polish](ui-polish.md) | Typography, visual design, layout, colors |
| [Forms & Controls](forms-controls.md) | Inputs, buttons, form submission |
| [Touch & Accessibility](touch-accessibility.md) | Mobile, touch devices, keyboard nav, a11y |
| [Component Design](component-design.md) | Compound components, composition, props API |
| [Marketing](marketing.md) | Landing pages, blogs, docs sites |
| [Performance](performance.md) | Virtualization, preloading, optimization |

## Core Principles

### 1. No Layout Shift

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.

### 2. Touch-First, Hover-Enhanced

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.

### 3. Keyboard Navigation

Tabbing should work consistently. Only allow tabbing through visible elements. Ensure keyboard navigation scrolls elements into view with `scrollIntoView()`.

### 4. Accessibility by Default

Every animation needs `prefers-reduced-motion` support. Every icon button needs an aria label. Every interactive element needs proper focus states.

### 5. Speed Over Delight

Product UI should be fast and purposeful. Skip animations for frequently-used interactions. Marketing pages can be more elaborate.

## Decision Flowcharts

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Quick Reference → Core Principles → 1. No Layout Shift → 2. Touch-First, Hover-Enhanced → 3. Keyboard Navigation → 4. Accessibility by Default
terms    -> A comprehensive guide for building polished, accessible web interfaces based on Emil Kowalski's design engineering practices. · Dynamic elements should cause no layout shift. · Design for touch first, then add hover enhancements. · Tabbing should work consistently. · Every animation needs prefers-reduced-motion support. · Product UI should be fast and purposeful.
files/cmd -> font-variant-numeric: tabular-nums · scrollIntoView() · prefers-reduced-motion · transition: all · @media (hover: hover) · height · width · transform
body sha256 -> 6e853b5b0ebc