# Critical Review Patterns Recommended by emil-design-eng

> Discover emil-design-eng's critical review patterns. Learn to use single markdown tables and a 12-item checklist for superior UI code changes and interactions. Improve your code reviews today.

- Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills)
- Tags: best-practices
- Published: 2026-08-07

---

**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`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) [lines 38-74](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L38-L74), 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`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) [lines 38-49](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L38-L49), 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

```markdown
| 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](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L64-L66) specifically targets `transition: all` as an anti-pattern.

### ❌ Avoid: Generic Transitions

```css
.button {
  transition: all 300ms;
}

```

### ✅ Prefer: Explicit Property Lists

```css
.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](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L60-L74) of [`SKILL.md`](https://github.com/emilkowalski/skills/blob/main/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](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L108-L118) to replace browser defaults:

```css
: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:

```css
.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`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) [lines 50-58](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L50-L58), 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`](https://github.com/emilkowalski/skills/blob/main/SKILL.md) [lines 64-66](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L64-L66), `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`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) [lines 108-118](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md#L108-L118). These values are tuned for perceived responsiveness rather than mathematical symmetry.