Critical Review Patterns Recommended by emil-design-eng

Use a single markdown table with Before, After, and Why columns for every UI code change, never use Before/After lists, and follow a strict 12-item checklist for animation and interaction quality.

The emil-design-eng skill in emilkowalski/skills defines a rigorous, evidence-based review methodology specifically for UI engineering work. As implemented in the source file skills/emil-design-eng/SKILL.md lines 38-74, these patterns force reviewers to surface concrete differences and justify every change with explicit reasoning.

The Single-Table Review Format

The cornerstone of the emil-design-eng critical review patterns is one markdown table per issue with three columns:

Column	Purpose
Before	Exact code as it exists now
After	The proposed replacement code
Why	Concise rationale for the change

This structure eliminates ambiguity. Reviewers cannot hide behind vague suggestions—they must demonstrate precisely what changes and justify it.

In skills/emil-design-eng/SKILL.md lines 38-49, the required table format is specified explicitly. The skill rejects alternative formats. Lines 50-58 show a deliberately incorrect example using "Before:" and "After:" lists, which violates the methodology.

Correct Review Table Example

| Before                                            | After                                            | Why |
| ------------------------------------------------- | ------------------------------------------------ | ---- |
| `transition: all 300ms`                           | `transition: transform 200ms ease-out`          | Specify exact property; avoid "all" |
| `transform: scale(0)`                             | `transform: scale(0.95); opacity: 0`            | Elements never appear from nothing |
| `ease-in` on dropdown                             | `ease-out` with custom curve                     | `ease-in` feels sluggish |
| No `:active` state on button                      | `transform: scale(0.97)` on `:active`            | Buttons must feel responsive |
| `transform-origin: center` on popover            | `transform-origin: var(--transform-origin)`     | Popovers scale from their trigger |

Be Explicit About Changed Properties

Generic CSS shortcuts trigger immediate flagging. The emil-design-eng checklist lines 64-66 specifically targets transition: all as an anti-pattern.

❌ Avoid: Generic Transitions

.button {
  transition: all 300ms;
}

✅ Prefer: Explicit Property Lists

.button {
  transition: transform 200ms ease-out, opacity 200ms ease-out;
}

Specifying exact properties prevents unintended side effects, enables better performance optimization, and makes the code's intent transparent to future maintainers.

The Complete Review Checklist

The emil-design-eng critical review patterns include a comprehensive checklist in lines 60-74 of SKILL.md:

• Replace transition: all with explicit property declarations
• Avoid scale(0) entry animations — start from scale(0.95) with opacity instead
• Swap ease-in for ease-out or a custom cubic-bezier curve
• Ensure popovers use trigger-aware transform-origin
• Remove animations on keyboard-initiated actions
• Keep durations under 300ms for UI-focused animations
• Add media-query guards for hover effects on touch devices
• Prefer CSS transitions over keyframes for interruptibility
• Use hardware-accelerated transforms instead of Framer Motion x/y props under heavy load
• Make exit animations faster than enter animations, with strategic staggering

Custom Easing Curves

The skill defines specific cubic-bezier values in lines 108-118 to replace browser defaults:

:root {
  --ease-out: cubic-bezier(0.23, 1, 0.32, 1);
  --ease-out-expo: cubic-bezier(0.19, 1, 0.22, 1);
}

.toast {
  transition: transform 150ms var(--ease-out), opacity 150ms var(--ease-out);
}

Standard ease-in curves feel sluggish to users; these custom values provide snappier, more responsive-feeling interfaces.

Accessibility: Respect Reduced Motion

The emil-design-eng patterns include mandatory accessibility guards. Always wrap animations in prefers-reduced-motion checks:

.menu {
  transition: transform 200ms var(--ease-out), opacity 200ms var(--ease-out);
}

@media (prefers-reduced-motion: reduce) {
  .menu {
    transition: opacity 0.2s ease; /* keep only subtle opacity */
  }
}

Summary

• One table per issue: Before / After / Why columns only — no lists, no prose descriptions
• Explicit property changes: Never transition: all; always specify exact properties
• Custom curves over defaults: Replace ease-in with hardware-accelerated custom easing
• Checklist-driven reviews: 12 specific items covering entry/exit animations, transform origins, keyboard interactions, and performance
• Accessibility mandatory: Include prefers-reduced-motion guards for all animations

Frequently Asked Questions

What happens if I use "Before:" and "After:" lists instead of a table?

The emil-design-eng skill explicitly prohibits this format. In skills/emil-design-eng/SKILL.md lines 50-58, this is shown as the wrong way to present changes. Lists obscure comparisons and remove the structural pressure to provide concise reasoning in a dedicated column.

Why does the checklist ban transition: all?

According to SKILL.md lines 64-66, transition: all causes unintended side effects when any property changes, triggers excess browser recalculation, and hides developer intent. Explicit property lists are self-documenting and performant.

Where are the custom easing curve values defined?

The specific cubic-bezier values for --ease-out, --ease-out-expo, and other curves are documented in skills/emil-design-eng/SKILL.md lines 108-118. These values are tuned for perceived responsiveness rather than mathematical symmetry.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}