# What Is the `emil-design-eng` Foundational Skill? A Deep Dive into Emil Kowalski's UI Philosophy > Uncover the emil-design-eng foundational skill. Emil Kowalski's UI philosophy focuses on disciplined taste, invisible details, and precise animation for UIs that feel right. - Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills) - Tags: deep-dive - Published: 2026-08-07 --- **The `emil-design-eng` foundational skill encodes Emil Kowalski's design-engineering philosophy, guiding developers to build UI that "feels right" through disciplined taste, invisible details, and precise animation decisions.** The `emil-design-eng` skill is a structured knowledge base from the [emilkowalski/skills](https://github.com/emilkowalski/skills) repository. It functions as a **design-engineering playbook** that agents or developers consult when refining user interface components. This article examines what the `emil-design-eng` skill defines, how it enforces quality, and why its framework produces superior software experiences. --- ## What the `emil-design-eng` Skill Defines The `emil-design-eng` skill lives at [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) and opens with a clear mission statement: > "This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great." This foundational skill does not teach basic UI patterns. Instead, it establishes **mental models** for making judgment calls—the kind of nuanced decisions that separate functional interfaces from exceptional ones. --- ## Core Philosophy of the `emil-design-eng` Skill Three interconnected principles anchor the skill's approach to design engineering. ### Taste Is Trained, Not Innate Good taste is a **learned instinct** built through deliberate study and relentless practice. The `emil-design-eng` skill explicitly rejects the notion that design sensibility is genetic or magical. Developers cultivate taste by analyzing great work, understanding *why* it works, and applying those lessons repeatedly. ### Unseen Details Compound Tiny details that users never consciously notice aggregate into experiences described as "stunning," "magical," or "just right." The skill emphasizes that **polish lives in the margins**—micro-interactions, timing adjustments, and visual hierarchies that escape explicit attention but shape emotional response. ### Beauty Is Leverage Excellent defaults, subtle animations, and refined visual polish differentiate products in crowded markets. The `emil-design-eng` skill frames aesthetic refinement not as decoration but as **competitive advantage**. --- ## Mandatory Review Format: Enforcing the `emil-design-eng` Standard The skill imposes structural discipline through a required documentation format. When suggesting UI changes, agents must present findings in a **Markdown table with three columns**: | Column | Purpose | |--------|---------| | **Before** | Current state or problematic implementation | | **After** | Proposed improvement with specific implementation | | **Why** | Rationale grounded in the skill's principles | This format forces explicit justification and prevents vague recommendations. Every entry in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) (lines 38–48) reinforces that documentation clarity drives implementation quality. --- ## Animation Decision Framework in `emil-design-eng` Animation represents a primary domain where the skill applies systematic rigor. Before authoring any motion, developers must answer four structured questions as defined in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) (lines 66–108). ### 1. Should This Animate at All? The skill provides a **frequency-based matrix** for this decision: - **Keyboard actions** → Never animate (speed is paramount) - **Frequent interactions** → Subtle or no animation (avoid fatigue) - **Occasional UI** → Standard animation acceptable - **Rare/celebratory moments** → More elaborate motion permitted This matrix appears in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) (lines 66–75) and prevents the common anti-pattern of animating everything indiscriminately. ### 2. What Is the Purpose? Animations must serve one of five functional categories: - **Spatial consistency** — Maintain orientation during navigation - **State indication** — Clarify mode changes or selections - **Explanation** — Reveal cause-and-effect relationships - **Feedback** — Confirm user actions - **Prevent jarring changes** — Smooth transitions that would otherwise disorient Purposeless motion violates the `emil-design-eng` standard according to lines 81–91 of the source file. ### 3. What Easing Should It Use? The skill mandates **custom cubic-bezier curves** for all UI animations. Critically, generic `"ease-in"` is **forbidden**—it feels sluggish and unresponsive. Lines 95–108 of [`SKILL.md`](https://github.com/emilkowalski/skills/blob/main/SKILL.md) specify that easing curves must be deliberately chosen and documented. ### 4. How Fast Should It Be? UI animations in the `emil-design-eng` framework stay within disciplined duration windows. While the excerpt cuts off, the skill's philosophy implies aggressive performance constraints—FAST UX patterns that respect user time and maintain system responsiveness. --- ## Applying the `emil-design-eng` Skill in Practice Developers and AI agents invoke this skill when: - Reviewing pull requests for UI components - Refining animation implementations - Establishing design system defaults - Mentoring team members on taste development The skill's structured format ensures recommendations are **reproducible, teachable, and measurable**—transforming subjective "this feels off" feedback into actionable engineering specifications. --- ## Summary - The `emil-design-eng` foundational skill encodes Emil Kowalski's design-engineering philosophy in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) - It treats **taste as trainable**, **invisible details as compound leverage**, and **beauty as product advantage** - A **mandatory review format** (Before/After/Why table) enforces documentation discipline - The **animation decision framework** requires answering four questions before any motion implementation - **Custom cubic-bezier curves** are required; generic `"ease-in"` easing is explicitly prohibited --- ## Frequently Asked Questions ### How does the `emil-design-eng` skill differ from general design guidelines? The `emil-design-eng` skill focuses on **judgment and philosophy** rather than prescriptive rules. While most design systems specify colors and spacing, this skill trains developers to make nuanced decisions about animation, polish, and invisible details through structured mental models. ### Can the `emil-design-eng` skill be used with any frontend framework? Yes. According to the source implementation in `emilkowalski/skills`, the principles are **framework-agnostic**. The animation timing and easing specifications translate across CSS, JavaScript, Swift, or any platform supporting cubic-bezier curves. ### Why does the skill forbid "ease-in" easing specifically? The `emil-design-eng` skill prohibits `"ease-in"` because it creates **perceived sluggishness**—motion that starts slow feels unresponsive in interactive UI. The framework requires custom cubic-bezier curves that prioritize snappy initiation and natural deceleration, as documented in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) (lines 95–108). ### Who benefits most from applying the `emil-design-eng` skill? Design engineers, frontend developers building component libraries, and product teams seeking **differentiated polish** gain the most value. The skill particularly benefits organizations where engineering and design collaboration needs explicit shared vocabulary for quality standards.