diff --git a/.agents/index.md b/.agents/index.md
index 01316aeb9..ea6eee1cb 100644
--- a/.agents/index.md
+++ b/.agents/index.md
@@ -2,6 +2,33 @@
TanStack.com marketing site built with TanStack Start.
+## Core principles for every task
+
+Before writing code, walk this ladder. Stop at the first answer that works.
+
+1. **Does this need to exist?** → no: skip it (YAGNI)
+2. **Already in this codebase?** → reuse it, don't rewrite
+3. **Stdlib does it?** → use it
+4. **Native platform feature?** → use it
+5. **Installed dependency?** → use it
+6. **One line?** → one line
+7. **Only then:** the minimum that works
+
+Inspired by https://github.com/DietrichGebert/ponytail
+
+### Abstraction & repetition
+
+- **KISS** — keep it simple, stupid. Boring code beats clever code.
+- **WET > DRY** — write everything twice (or more) before abstracting. Three similar usages with diverging needs is the cue to extract; two is not.
+- Premature DRY couples unrelated code through a shared abstraction that ends up fighting both callers. Duplication is cheaper than the wrong abstraction.
+
+### What this means in practice
+
+- Don't add error handling, fallbacks, or validation for cases that can't happen.
+- Don't introduce helpers, wrappers, or config knobs "for later."
+- Don't refactor surrounding code while fixing a bug.
+- When tempted to abstract: count the call sites and check they actually want the same behavior. If not, leave the duplication.
+
## Essentials
- Package manager: `pnpm`
diff --git a/.agents/skills/design-motion-principles/SKILL.md b/.agents/skills/design-motion-principles/SKILL.md
new file mode 100644
index 000000000..0a52ee0fd
--- /dev/null
+++ b/.agents/skills/design-motion-principles/SKILL.md
@@ -0,0 +1,124 @@
+---
+name: design-motion-principles
+description: "Motion and interaction design expert based on Emil Kowalski, Jakub Krehel, and Jhey Tompkins' techniques. Two modes — build interactive components with purposeful motion, or audit existing animations to catch AI-slop motion patterns (audit emits a branded HTML report with looping demos). Use when creating, adding, animating, or reviewing UI motion: transitions, hover states, micro-interactions, enter/exit animations, or any motion design work in React, Framer Motion, CSS, or HTML. Provides per-designer perspectives with context-aware weighting."
+---
+
+# Design Motion Principles
+
+You are a senior design engineer specializing in motion and interaction design. This skill operates in two modes:
+
+- **Create** — Build interactive components with purposeful motion → `workflows/create.md`
+- **Audit** — Review existing motion design and report findings → `workflows/audit.md`
+
+**Scope**: Web and app UI motion — HTML/CSS, React, Framer Motion / Motion, iOS/Android transitions, design system animations. The frequency framework still applies to other motion work (game engines, Lottie, Rive, video), but designer-specific techniques may not translate.
+
+---
+
+## STEP 0: Detect Mode (DO THIS FIRST)
+
+| Signal in the request | Mode |
+| -------------------------------------------------------------------------------- | ------------ |
+| "build", "create", "add animation", "animate this", "implement", "make it feel…" | **Create** |
+| "audit", "review", "evaluate", "check", "feedback on", "is this motion good" | **Audit** |
+| Ambiguous (e.g. "look at this modal animation") | Ask the user |
+
+For ambiguous requests, if `AskUserQuestion` is available, present:
+
+- **Create** — Build or improve the component's motion
+- **Audit** — Review existing motion and report findings
+
+Otherwise ask in plain text: "Should I build/improve the motion (Create mode), or review existing motion and report findings (Audit mode)?"
+
+**Once the mode is known, read the matching workflow file and follow it exactly.**
+
+---
+
+## The Three Designers
+
+- **Emil Kowalski** (Linear, ex-Vercel) — Restraint, speed, purposeful motion. Best for productivity tools.
+- **Jakub Krehel** (jakub.kr) — Subtle production polish, professional refinement. Best for shipped consumer apps.
+- **Jhey Tompkins** (@jh3yy) — Playful experimentation, CSS innovation. Best for creative sites, kids apps, portfolios.
+
+> These three lenses distill each designer's _publicly published_ work — courses, articles, talks, and open-source projects. The weighting framework and the "lens" framing are this skill's interpretation of their principles, named in tribute; they are not authored or endorsed by the designers themselves.
+
+Each designer answers a different question:
+
+- **Emil** — _"Should this animate at all?"_
+- **Jakub** — _"Is this subtle and polished enough for production?"_
+- **Jhey** — _"What could this become?"_
+
+**Critical insight**: These perspectives are context-dependent, not universal rules. A kids' app should prioritize Jakub + Jhey (polish + delight), not Emil's productivity-focused speed rules. Both modes weight the designers by project context before doing anything.
+
+---
+
+## Context-to-Perspective Mapping
+
+| Project Type | Primary | Secondary | Selective |
+| ----------------------------------- | ------- | --------- | ---------------------------------- |
+| Productivity tool (Linear, Raycast) | Emil | Jakub | Jhey (onboarding only) |
+| Kids app / Educational | Jakub | Jhey | Emil (high-freq game interactions) |
+| Creative portfolio | Jakub | Jhey | Emil (high-freq interactions) |
+| Marketing/landing page | Jakub | Jhey | Emil (forms, nav) |
+| SaaS dashboard | Emil | Jakub | Jhey (empty states) |
+| Mobile app | Jakub | Emil | Jhey (delighters) |
+| E-commerce | Jakub | Emil | Jhey (product showcase) |
+
+---
+
+## Core Principles (Both Modes)
+
+### The Frequency Gate
+
+Before adding or approving any animation, ask how often the user triggers it:
+
+| Frequency | Recommendation |
+| ------------------- | ------------------------------------- |
+| Rare (monthly) | Delightful, expressive motion welcome |
+| Occasional (daily) | Subtle, fast motion |
+| Frequent (100s/day) | No animation or instant transition |
+| Keyboard-initiated | Never animate |
+
+### Duration Guidelines (Context-Dependent)
+
+| Context | Guideline |
+| ---------------------------- | -------------------------- |
+| Productivity UI (Emil) | Under 300ms — 180ms ideal |
+| Production polish (Jakub) | 200-500ms for smoothness |
+| Creative/kids/playful (Jhey) | Whatever serves the effect |
+
+**Do not universally flag or cap durations.** Check the context weighting first.
+
+### The Golden Rule
+
+> "The best animation is that which goes unnoticed."
+
+If users comment "nice animation!" on every interaction, it's probably too prominent for production. (Exception: kids apps and playful contexts where delight IS the goal.)
+
+### Accessibility is NOT Optional
+
+Every animation — generated in Create mode or reviewed in Audit mode — must handle `prefers-reduced-motion`. No exceptions. See `references/accessibility.md`.
+
+---
+
+## Reference Index
+
+| File | Contents | Load When |
+| -------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
+| [Motion Cookbook](references/motion-cookbook.md) | All motion recipes — enter/exit, easing, springs, clip-path, @property, FLIP, scroll-driven | Create mode (always); Audit mode for implementation recommendations |
+| [Creation Gotchas](references/creation-gotchas.md) | Claude's failure modes when writing motion | Create mode (always) |
+| [Audit Checklist](references/audit-checklist.md) | Systematic audit checklist | Audit mode (always) |
+| [Anti-Checklist](references/anti-checklist.md) | Quality gate — AI-slop motion categories + anti-patterns to flag | Audit mode (always) |
+| [Emil Kowalski](references/emil-kowalski.md) | Restraint philosophy, frequency rule, decision frameworks | Either mode, if Emil is weighted |
+| [Jakub Krehel](references/jakub-krehel.md) | Production polish philosophy and decision frameworks | Either mode, if Jakub is weighted |
+| [Jhey Tompkins](references/jhey-tompkins.md) | Playful experimentation philosophy and frameworks | Either mode, if Jhey is weighted |
+| [Accessibility](references/accessibility.md) | prefers-reduced-motion, vestibular safety | Both modes (mandatory) |
+| [Performance](references/performance.md) | GPU optimization, will-change, layout thrash | Either mode, for complex animations |
+| [Output Format](references/output-format.md) | Audit report template — HTML mode (default) + terminal mode (flag) | Audit mode only |
+| [Demo Shell](references/demo-shell.html) | Visual container template for per-finding demo cards in the HTML report | Audit mode, HTML output |
+
+## Workflow Index
+
+| Workflow | Purpose |
+| ----------------------------- | ------------------------------------------------------------ |
+| [Create](workflows/create.md) | Build interactive components with purposeful motion |
+| [Audit](workflows/audit.md) | Review existing motion design, produce a per-designer report |
diff --git a/.agents/skills/design-motion-principles/references/accessibility.md b/.agents/skills/design-motion-principles/references/accessibility.md
new file mode 100644
index 000000000..99247ab02
--- /dev/null
+++ b/.agents/skills/design-motion-principles/references/accessibility.md
@@ -0,0 +1,52 @@
+# Accessibility
+
+**This is not optional.** Motion can cause discomfort, nausea, or distraction for many users.
+
+---
+
+## Respect User Preferences
+
+```css
+@media (prefers-reduced-motion: reduce) {
+ *,
+ *::before,
+ *::after {
+ animation-duration: 0.01ms !important;
+ animation-iteration-count: 1 !important;
+ transition-duration: 0.01ms !important;
+ scroll-behavior: auto !important;
+ }
+}
+```
+
+**What this does**: Effectively disables animations while preserving final states (so layouts don't break).
+
+---
+
+## Functional vs. Decorative Motion
+
+| Type | Purpose | Reduced Motion Behavior |
+| -------------- | ----------------------------------------------------------- | ---------------------------------------------------------- |
+| **Functional** | Indicates state changes, spatial relationships, orientation | May need alternative (instant state change, no transition) |
+| **Decorative** | Pure delight, visual interest | Can be fully removed |
+
+**The test**: Does removing this animation break the user's ability to understand what happened? If yes, it's functional.
+
+---
+
+## Motion Sensitivity Considerations
+
+- Avoid large-scale motion (full-screen transitions, parallax)
+- Avoid continuous or looping animations that can't be paused
+- Provide pause controls for any ambient animation
+- Be especially careful with vestibular triggers: zooming, spinning, parallax
+
+---
+
+## Implementation Checklist
+
+- [ ] Tested with `prefers-reduced-motion: reduce` enabled
+- [ ] No vestibular triggers (excessive zoom, spin, parallax)
+- [ ] Looping animations can be paused
+- [ ] Functional animations have non-motion alternatives
+- [ ] Users can complete all tasks with animations disabled
diff --git a/.agents/skills/design-motion-principles/references/anti-checklist.md b/.agents/skills/design-motion-principles/references/anti-checklist.md
new file mode 100644
index 000000000..e11cb002e
--- /dev/null
+++ b/.agents/skills/design-motion-principles/references/anti-checklist.md
@@ -0,0 +1,295 @@
+# Anti-Checklist
+
+This file is the audit's quality gate. The categories below describe motion patterns to **flag** in audited code — AI-slop tells at the top (where most 2026 motion problems live), followed by perspective-specific anti-patterns from Emil, Jakub, and Jhey, then general motion mistakes and code-shaped red flags. When audited code matches a pattern here, the audit surfaces a finding and the agent generates a per-finding motion suggestion by reading the relevant philosophy reference (`emil-kowalski.md`, `jakub-krehel.md`, `jhey-tompkins.md`).
+
+The file frames patterns as "things to flag," not "mistakes to avoid" — language that makes the audit's adversarial posture explicit.
+
+---
+
+## AI-Slop Motion Patterns
+
+These are the recognizable motion fingerprints of AI-generated UIs in 2026. They're not always wrong in isolation — what makes them slop is _frequency_ and _uniformity_. Finding one instance is normal polish; finding the same pattern slapped across the codebase is the tell. Each category includes a flagging heuristic below the definition so the audit isn't tripped by single intentional uses.
+
+---
+
+### Pulsing indicators
+
+Glowing dots, breathing CTAs, throbbing rings, "live"/"online"/"recording"/"AI active" pulse animations, dark-mode pulse glows — any looped scale/opacity pulse used to draw attention to a status element.
+
+**Flag when you see:**
+
+- `@keyframes` rules with names containing `pulse`, `glow`, `breathe`, `throb`
+- `animation: ... infinite` on small UI elements (dots, badges, status indicators)
+- `box-shadow` or `opacity` loops on status icons
+- Tailwind `animate-pulse` on indicator dots or active-state elements
+
+**Heuristic:** Flag _any_ instance. Pulsing indicators are almost always slop — the only exception is a single brand element with explicit design rationale stated in code comments or design docs.
+
+**Fix lens:** Emil — purposeful restraint. See `references/emil-kowalski.md`.
+
+---
+
+### Blur-everywhere entrances
+
+`filter: blur(Npx)` applied to every entering element on mount — sections, cards, images, paragraphs. Jakub's enter recipe (`opacity + translateY + blur`) is excellent in moderation; AI-slop versions apply it uniformly across the page.
+
+**Flag when you see:**
+
+- `initial={{ filter: 'blur(Npx)' }}` or `from { filter: blur(Npx); }` on multiple distinct components in the same view
+- Identical blur values (e.g., `blur(4px)`) repeated across components without context distinction
+- Blur on text-bearing entrances (headings, paragraphs) where it impairs first-paint readability
+
+**Heuristic:** Flag when ≥3 distinct components in the same view share the same `filter: blur()` enter pattern. Single uses with intent (a hero element, a modal) are fine.
+
+**Fix lens:** Jakub — production polish, but selective. See `references/jakub-krehel.md`.
+
+---
+
+### Hover-scale-on-everything
+
+`transform: scale(1.0X)` on `:hover` applied to every card, button, and image without intent. The micro-bounce-on-hover feels polished in moderation; AI-slop versions slap it on indiscriminately.
+
+**Flag when you see:**
+
+- `transition` rules with `transform: scale(1.0X)` on `:hover` across multiple card/button/image components
+- Identical scale values (e.g., `scale(1.05)`) repeated across selectors with no discriminating context
+- Tailwind `hover:scale-105` applied to grids of repeated items
+
+**Heuristic:** Flag when ≥3 distinct components share the same `transform: scale(1.0X)` on `:hover` with no other discriminating selector context. Single intentional uses (e.g., a primary CTA) are fine.
+
+**Fix lens:** Emil for utility-shaped elements (none); Jakub for product-shaped elements (selective). See `references/emil-kowalski.md` and `references/jakub-krehel.md`.
+
+---
+
+### Stagger-spam-on-every-list
+
+`stagger`, `staggerChildren`, or hand-rolled `animation-delay: calc(var(--i) * 50ms)` patterns applied to every list, grid, or repeated-element block. Jhey-style stagger on a deliberate moment is delightful; AI-slop spreads it across every list as default polish.
+
+**Flag when you see:**
+
+- `staggerChildren` in framer-motion `variants` across multiple list components
+- `animation-delay: calc(...)` with item-index multipliers across multiple components
+- Sequential delays applied to lists that don't read as a moment (search results, settings options, table rows)
+
+**Heuristic:** Flag when ≥2 lists in the same view use stagger entrance. One intentional moment is fine; two or more is the tell.
+
+**Fix lens:** Emil for utility lists (no stagger); Jhey for delight moments (selective). See `references/emil-kowalski.md` and `references/jhey-tompkins.md`.
+
+---
+
+### Bouncy-springs-on-utility-actions
+
+`type: 'spring'` with bounce on dropdown opens, toggle switches, menu reveals, modal entrances — utility actions where bounce reads as "playful" but the action itself is productivity-oriented.
+
+**Flag when you see:**
+
+- `transition={{ type: 'spring', bounce: > 0 }}` on dropdowns, popovers, menus, toggles, modal opens, settings panels
+- CSS `cubic-bezier(...)` with overshoot values on utility elements
+- Identical spring configs across utility components
+
+**Heuristic:** Flag _any_ spring with bounce > 0 on a utility action (dropdown, menu, toggle, modal, settings panel). Bounce belongs on playful elements — celebration moments, kids apps, intentional delight — not productivity UI.
+
+**Fix lens:** Emil — speed and purpose. See `references/emil-kowalski.md`.
+
+---
+
+### Uniform-fade-in-on-every-element
+
+Identical `opacity + translateY` (with or without blur) enter animations applied to every section, card, paragraph, and heading. The "polished entrance" treatment from Jakub used uniformly across the page, regardless of element type or context.
+
+**Flag when you see:**
+
+- Multiple components sharing identical `initial`/`animate` opacity+translateY values
+- `whileInView` with identical viewport options applied to every block on a page
+- CSS keyframes with generic names (`fadeInUp`, `enter`, `reveal`) attached to many selectors
+
+**Heuristic:** Flag when ≥4 distinct components share identical enter animations (same opacity, same translateY, same duration, same easing). Three is acceptable polish baseline; four is uniformity slop.
+
+**Fix lens:** Jakub — selective polish with hierarchy. See `references/jakub-krehel.md`.
+
+---
+
+### Motion-on-mount-for-static-content
+
+Entrance animations on headings, body paragraphs, navigation links, and other content that should appear instantly. The "fade in everything" pattern that delays reading and makes the page feel sluggish.
+
+**Flag when you see:**
+
+- `initial`/`animate` on ``, ``, ` `, `` elements
+- `whileInView` on body copy (paragraphs, articles, prose)
+- `animation` rules on text-only components without functional reason
+
+**Heuristic:** Flag any motion on a text-only or navigation element when the motion's only purpose is the entrance itself. Carousels, sliders, and hero animations are fine when the motion serves a function (orientation, narrative pacing, attention direction).
+
+**Fix lens:** Emil — animations should serve a purpose, not announce themselves. See `references/emil-kowalski.md`.
+
+---
+
+## From Emil's Perspective (Purposeful Restraint)
+
+- **Animating high-frequency interactions** — If users trigger this 100s of times daily, remove the animation
+- **Animating keyboard-initiated actions** — Keyboard shortcuts should NEVER animate
+- **Animations over 300ms** — UI animations should be under 300ms; 180ms feels more responsive than 400ms
+- **Animating from scale(0)** — Start from `scale(0.9)` or higher for natural motion
+- **Same tooltip behavior everywhere** — First tooltip: delayed + animated. Subsequent: instant
+- **Using default CSS easing** — Built-in `ease` and `ease-in-out` lack strength; use custom curves
+- **Ignoring transform-origin** — Dropdowns should expand from their trigger, not center
+- **Expecting delight in productivity tools** — Users of high-frequency tools prioritize speed over delight
+- **Using keyframes for interruptible animations** — Keyframes can't retarget mid-flight; use CSS transitions with state
+- **CSS variables for frequent updates** — Causes expensive style recalculation; update styles directly on element
+- **Distance thresholds for dismissal** — Use velocity (distance/time) instead; fast short gestures should work
+- **Abrupt boundary stops** — Use damping; things slow down before stopping in real life
+
+---
+
+## From Jakub's Perspective (Production Polish)
+
+- **Making enter and exit animations equally prominent** — Exits should be subtler
+- **Using solid borders when shadows would adapt better** — Especially on varied backgrounds
+- **Forgetting optical alignment** — Buttons with icons, play buttons, asymmetric shapes
+- **Over-animating** — If users notice the animation itself, it's too much
+- **Using the same animation everywhere** — Context should drive timing and easing choices
+- **Ignoring hover state transitions** — Even small transitions (150-200ms) feel more polished than instant changes
+
+---
+
+## From Jhey's Perspective (Creative Learning)
+
+- **Filtering ideas based on "usefulness" too early** — Make first, judge later
+- **Not documenting random creative sparks** — Keep notebooks everywhere, including by your bed
+- **Thinking CSS art is useless** — It teaches real skills (clip-path, layering, complex shapes)
+- **Focusing on "How do I learn X?" instead of "How do I make Y?"** — Let ideas drive learning
+- **Following tutorials without experimenting** — Tutorials teach techniques; experimentation teaches problem-solving
+- **Giving up when something doesn't work** — The struggle is where learning happens
+
+---
+
+## General Motion Design Mistakes
+
+- **Animating layout-triggering properties** (width, height, top, left) — Use transform instead
+- **No animation at all** — Instant state changes feel broken to modern users
+- **Same duration for all animations** — Smaller elements should animate faster
+- **Forgetting `prefers-reduced-motion`** — Not optional
+
+_Note: Duration is designer-dependent. Emil prefers under 300ms for productivity tools. Jakub and Jhey may use longer durations when polish or effect warrants it._
+
+---
+
+## Red Flags in Code Review
+
+Watch for these patterns:
+
+```jsx
+// BAD: Animating layout properties
+animate={{ width: 200, height: 100 }}
+
+// GOOD: Use transform
+animate={{ scale: 1.2 }}
+```
+
+```jsx
+// BAD: Same animation for enter and exit
+initial={{ opacity: 0, y: 20 }}
+exit={{ opacity: 0, y: 20 }}
+
+// GOOD: Subtler exit
+initial={{ opacity: 0, y: 20 }}
+exit={{ opacity: 0, y: -8 }}
+```
+
+```css
+/* BAD: No reduced motion support */
+.animated {
+ animation: bounce 1s infinite;
+}
+
+/* GOOD: Respects user preference */
+@media (prefers-reduced-motion: no-preference) {
+ .animated {
+ animation: bounce 1s infinite;
+ }
+}
+```
+
+```css
+/* BAD: will-change everywhere */
+* {
+ will-change: transform;
+}
+
+/* GOOD: Targeted will-change */
+.animated-button {
+ will-change: transform, opacity;
+}
+```
+
+```jsx
+// BAD: Animating from scale(0) (Emil)
+initial={{ scale: 0 }}
+animate={{ scale: 1 }}
+
+// GOOD: Start from higher scale
+initial={{ scale: 0.9, opacity: 0 }}
+animate={{ scale: 1, opacity: 1 }}
+```
+
+```jsx
+// Per Emil: Too slow for productivity UI
+transition={{ duration: 0.4 }}
+
+// Per Emil: Fast, snappy (but Jakub/Jhey might use 0.4 for polish)
+transition={{ duration: 0.18 }}
+```
+
+```css
+/* BAD: Dropdown expanding from center (Emil) */
+.dropdown {
+ transform-origin: center;
+}
+
+/* GOOD: Origin-aware animation */
+.dropdown {
+ transform-origin: top center;
+}
+```
+
+```css
+/* BAD: Keyframes can't be interrupted (Emil) */
+@keyframes slideIn {
+ from {
+ transform: translateY(100%);
+ }
+ to {
+ transform: translateY(0);
+ }
+}
+.toast {
+ animation: slideIn 400ms ease;
+}
+
+/* GOOD: Transitions can retarget mid-flight */
+.toast {
+ transform: translateY(100%);
+ transition: transform 400ms ease;
+}
+.toast.mounted {
+ transform: translateY(0);
+}
+```
+
+```javascript
+// BAD: CSS variables cause cascade recalc (Emil)
+element.style.setProperty('--drag-y', `${y}px`)
+
+// GOOD: Direct style update
+element.style.transform = `translateY(${y}px)`
+```
+
+```javascript
+// BAD: Distance threshold for dismissal (Emil)
+if (dragDistance > 100) dismiss()
+
+// GOOD: Velocity-based (fast short gestures work)
+const velocity = dragDistance / elapsedTime
+if (velocity > 0.11) dismiss()
+```
diff --git a/.agents/skills/design-motion-principles/references/audit-checklist.md b/.agents/skills/design-motion-principles/references/audit-checklist.md
new file mode 100644
index 000000000..5e73ec4c0
--- /dev/null
+++ b/.agents/skills/design-motion-principles/references/audit-checklist.md
@@ -0,0 +1,141 @@
+# Audit Checklist
+
+Use this checklist when reviewing motion design in any UI code.
+
+---
+
+## Philosophy Check (Do First)
+
+- [ ] **How often will users trigger this?** (Frequent = less/no animation — Emil's rule)
+- [ ] **Is this keyboard-initiated?** (If yes, don't animate — Emil's rule)
+- [ ] **Does this animation serve a purpose?** (orientation, feedback, continuity—not just decoration)
+- [ ] **Will users notice this animation consciously?** (If yes for production UI, probably too much)
+- [ ] **Have I tested this with `prefers-reduced-motion: reduce`?**
+- [ ] **Does this feel natural after the 10th interaction?** (Test repeatedly, not just once)
+- [ ] **Is the easing appropriate for my brand/context?**
+- [ ] **Is the duration appropriate for context?** (Emil prefers under 300ms; Jakub/Jhey may use longer for polish or effect)
+
+---
+
+## Motion Gap Analysis (Check BEFORE Reviewing Existing Animations)
+
+Conditional UI changes that **lack** animation are often worse than poorly-tuned animations:
+
+- [ ] **Searched for conditional renders** — `{condition && Demo Shell — design-motion-principles
+
+
+
+
+
+
+ Recommended motion title
+ 300ms · ease-out
+
+
+
+ Auto
+ Light
+ Dark
+
+
↻
+
+
+
+
+
+
+
Placeholder
+
+
+
+
(motion preview renders here per finding)
+
+
+
+
+
+ {isCopied ? (
+
+
+ ) : (
+
+
+ )}
+
+```
+
+**Why animate icon swaps?** Instant swaps feel jarring and can be missed. Animated transitions:
+
+- Draw attention to the state change
+- Feel responsive and polished
+- Give the user confidence their action registered
+
+---
+
+## 6. Shared Layout Animations (Jakub)
+
+### FLIP Technique via layoutId
+
+Motion's `layoutId` prop enables smooth transitions between completely different components:
+
+```jsx
+// In one location:
+';
+}
+
+@keyframes rainbow {
+ to {
+ --hue: 360;
+ }
+}
+```
+
+**Available types**: length, number, percentage, color, angle, time, integer, transform-list
+
+**Why this matters**: Without `@property`, CSS sees custom properties as strings. Strings can't interpolate—they just swap. With a declared type, the browser knows how to smoothly transition between values.
+
+### Decompose Complex Transforms
+
+Instead of animating a monolithic transform (which can't interpolate curved paths), split into typed properties:
+
+```css
+@property --x {
+ syntax: '';
+ initial-value: 0%;
+ inherits: false;
+}
+@property --y {
+ syntax: '';
+ initial-value: 0%;
+ inherits: false;
+}
+
+.ball {
+ transform: translateX(var(--x)) translateY(var(--y));
+ animation: throw 1s;
+}
+
+@keyframes throw {
+ 0% {
+ --x: -500%;
+ }
+ 50% {
+ --y: -250%;
+ }
+ 100% {
+ --x: 500%;
+ }
+}
+```
+
+This creates curved motion paths that would be impossible with standard transform animation—the ball arcs through space rather than moving in straight lines.
+
+### Scoped Variables for Dynamic Behavior (Jhey)
+
+CSS custom properties respect scope, enabling powerful patterns:
+
+```css
+.item {
+ --delay: 0;
+ animation-delay: calc(var(--delay) * 100ms);
+}
+.item:nth-child(1) {
+ --delay: 0;
+}
+.item:nth-child(2) {
+ --delay: 1;
+}
+.item:nth-child(3) {
+ --delay: 2;
+}
+```
+
+Use scoped variables to create varied behavior from a single animation definition.
+
+---
+
+## 8. 3D CSS (Jhey)
+
+### Think in Cuboids
+
+> "Think in cubes instead of boxes" — Jhey Tompkins
+
+Complex 3D scenes are assemblies of cube-shaped elements (like LEGO). Decompose any 3D object into cuboids.
+
+### Essential Setup
+
+```css
+.scene {
+ transform-style: preserve-3d;
+ perspective: 1000px;
+}
+```
+
+### Responsive 3D
+
+Use CSS variables for dimensions and `vmin` units:
+
+```css
+.cube {
+ --size: 10vmin;
+ width: var(--size);
+ height: var(--size);
+}
+```
+
+---
+
+## 9. Clip-Path Animations (Emil)
+
+### Why clip-path?
+
+- Hardware-accelerated rendering
+- No layout shifts
+- No additional DOM elements needed
+- Smoother than width/height animations
+
+### Basic Syntax
+
+```css
+clip-path: inset(top right bottom left);
+clip-path: circle(radius at x y);
+clip-path: polygon(coordinates);
+```
+
+### Image Reveal Effect
+
+```css
+.reveal {
+ clip-path: inset(0 0 100% 0); /* Hidden */
+ animation: reveal 1s forwards cubic-bezier(0.77, 0, 0.175, 1);
+}
+
+@keyframes reveal {
+ to {
+ clip-path: inset(0 0 0 0);
+ } /* Fully visible */
+}
+```
+
+### Tab Transitions
+
+Duplicate tab lists with different styling. Animate the overlay's clip-path to reveal only the active tab—creates smooth color transitions without timing issues.
+
+### Scroll-Driven with clip-path
+
+```javascript
+const clipPathY = useTransform(scrollYProgress, [0, 1], ['100%', '0%'])
+const motionClipPath = useMotionTemplate`inset(0 0 ${clipPathY} 0)`
+```
+
+### Text Mask Effect
+
+Stack elements with complementary clip-paths:
+
+```css
+.top {
+ clip-path: inset(0 0 50% 0);
+} /* Shows top half */
+.bottom {
+ clip-path: inset(50% 0 0 0);
+} /* Shows bottom half */
+```
+
+Adjust values on mouse interaction for seamless transitions.
+
+---
+
+## 10. Button & Interactive Feedback (Emil)
+
+### Scale on Press
+
+Add immediate tactile feedback:
+
+```css
+button:active {
+ transform: scale(0.97);
+}
+```
+
+### Don't Animate from scale(0)
+
+```jsx
+// BAD: Unnatural motion
+initial={{ scale: 0 }}
+
+// GOOD: Natural, gentle motion
+initial={{ scale: 0.9, opacity: 0 }}
+animate={{ scale: 1, opacity: 1 }}
+```
+
+### Tooltip Delay Pattern
+
+First tooltip in a group: delay + animation. Subsequent tooltips: instant.
+
+```css
+[data-instant] {
+ transition-duration: 0ms;
+}
+```
+
+### Blur as a Bridge
+
+When state transitions aren't smooth enough, add blur to mask imperfections:
+
+```css
+.transitioning {
+ filter: blur(2px);
+}
+```
+
+---
+
+## 11. CSS Transitions vs Keyframes (Emil)
+
+### Interruptibility Problem
+
+CSS keyframes can't be interrupted mid-animation. When users rapidly trigger actions, elements "jump" to new positions rather than smoothly retargeting.
+
+**Solution**: Use CSS transitions with state-driven classes:
+
+```jsx
+useEffect(() => {
+ setMounted(true)
+}, [])
+```
+
+```css
+.element {
+ transform: translateY(100%);
+ transition: transform 400ms ease;
+}
+.element.mounted {
+ transform: translateY(0);
+}
+```
+
+### Direct Style Updates for Performance
+
+CSS variables cause style recalculation across all children. For frequent updates (drag operations), update styles directly:
+
+```javascript
+// BAD: CSS variable (expensive cascade)
+element.style.setProperty('--drag-y', `${y}px`)
+
+// GOOD: Direct style (no cascade)
+element.style.transform = `translateY(${y}px)`
+```
+
+### Momentum-Based Dismissal
+
+Use velocity (distance / time) instead of distance thresholds:
+
+```javascript
+const velocity = dragDistance / elapsedTime
+if (velocity > 0.11) dismiss()
+```
+
+Fast, short gestures should work—users shouldn't need to drag far.
+
+### Damping for Natural Boundaries
+
+When dragging past boundaries, reduce movement progressively. Things in real life slow down before stopping.
+
+---
+
+## 12. Spring Physics (Emil)
+
+### Key Parameters
+
+| Parameter | Effect |
+| ------------- | ------------------------------------------------------ |
+| **Stiffness** | How quickly spring reaches target (higher = faster) |
+| **Damping** | How quickly oscillations settle (higher = less bounce) |
+| **Mass** | Weight of object (higher = more momentum) |
+
+### Spring for Mouse Position
+
+```javascript
+const springConfig = { stiffness: 300, damping: 30 }
+const x = useSpring(mouseX, springConfig)
+const y = useSpring(mouseY, springConfig)
+```
+
+Use `useSpring` for any value that should interpolate smoothly rather than snap—nothing in the real world changes instantly.
+
+### Interruptibility
+
+Great animations can be interrupted mid-play:
+
+- Framer Motion supports interruption natively
+- CSS transitions allow smooth interruption before completion
+- Test by clicking rapidly—animations should blend, not queue
+
+---
+
+## 13. Origin-Aware Animations (Emil)
+
+Animations should originate from their logical source:
+
+```css
+/* Dropdown from button should expand from button, not center */
+.dropdown {
+ transform-origin: top center;
+}
+```
+
+**Component library support:**
+
+- Base UI: `--transform-origin` CSS variable
+- Radix UI: `--radix-dropdown-menu-content-transform-origin`
+
+---
+
+## 14. Scroll-Driven Animations (Jhey)
+
+### The Core Problem
+
+Scroll-driven animations are tied to scroll **speed**. If users scroll slowly, animations play slowly. This feels wrong for most UI—you want animations to trigger at a scroll position, not be controlled by scroll speed.
+
+### Duration Control Pattern
+
+Use two coordinated animations:
+
+1. **Trigger animation**: Scroll-driven, toggles a custom property when element enters view
+2. **Main animation**: Traditional duration-based, activated via Style Query
+
+This severs the connection between scroll speed and animation timing—the animation runs over a fixed duration once triggered, regardless of how fast the user scrolled.
+
+### Progressive Enhancement
+
+Always provide fallbacks:
+
+```javascript
+// IntersectionObserver fallback for browsers without scroll-driven animation support
+if (!CSS.supports('animation-timeline', 'scroll()')) {
+ // Use IntersectionObserver instead
+}
+```
diff --git a/.agents/skills/design-motion-principles/references/output-format.md b/.agents/skills/design-motion-principles/references/output-format.md
new file mode 100644
index 000000000..7b2dd76a3
--- /dev/null
+++ b/.agents/skills/design-motion-principles/references/output-format.md
@@ -0,0 +1,357 @@
+# Output Format
+
+The audit produces one of two outputs:
+
+- **HTML mode (default)** — a self-contained `.html` file written to the audited project's `motion-audits/` directory and opened in the user's default browser. Each Critical or Important finding gets a live, looping CSS demo card beside it.
+- **Terminal mode (flag-triggered)** — a decorated-markdown report rendered inline in the conversation. Use when the user passes `--terminal`, `--inline`, `--no-html`, "show the full report inline," or any natural-language equivalent. No HTML file is written.
+
+Both modes carry the same audit content; only the rendering differs. Do not summarize — users want full per-lens perspectives.
+
+---
+
+## HTML mode
+
+### Canonical references
+
+| File | Role |
+| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `references/report-template.html` | **Source of truth.** Full worked example (fictional "Tally" habit tracker, React + Framer Motion). Every section, every token, every pattern. When in doubt about layout, structure, or styling, READ this file. |
+| `references/demo-shell.html` | Minimal isolated example of a single demo card with the per-finding slot pattern. Used as a per-finding template snippet. |
+
+The agent builds the report by reading these two files and adapting them to the audited project — same architecture, audit-specific content.
+
+### File structure
+
+Single self-contained `.html`. All CSS inlined. No external JS. Fonts loaded via Google Fonts CDN (Familjen Grotesk / Public Sans / Geist Mono) with full system-stack fallbacks so the file degrades gracefully offline.
+
+```
+
+
+
+ {project-name} motion audit — {ISO date}
+ ` with a `mono-label` "OVERALL" eyebrow.
+
+#### 01 · Lens summary
+
+3-row table, one row per practitioner. Columns: Lens (with name and weight chip) · Verdict (`Strong` / `Concern` / `Problem` / `Mixed` with a colored dot) · One-line read. Weight chips indicate `Primary` / `Secondary` / `Selective` per audit context.
+
+#### 02 · Where the timings land — duration-budget diagram
+
+Motion-native analog of thumb-first's thumb-zone diagram. A horizontal SVG (`viewBox="0 0 660 300"`) plots Tally's animations as numbered dots on a 0–600ms scale with four zone bands:
+
+| Zone | Range | Color |
+| ---------- | --------- | ------------------ |
+| Instant | 0–100ms | green (`--t-good`) |
+| Responsive | 100–300ms | green (`--t-good`) |
+| Deliberate | 300–500ms | amber (`--t-mid`) |
+| Sluggish | 500ms+ | red (`--t-slow`) |
+
+Animations with NO transition are plotted as hollow dashed circles at `x=40` (= 0ms). The paired key list to the right carries the action names and durations. A "What's off" block below explains the misalignments.
+
+The SVG uses CSS-class-driven fills (via an inline `
+
+
+
+
+
+
+
+
+ Motion audit · design-motion-principles
+ Tally — what to slow down, speed up, and finish
+
+ A pass over Tally's core loop — check-off, tab switches, the add-habit
+ sheet, and the streak milestones — read through three motion
+ practitioners' lenses, ordered by what users feel most and the order
+ to fix it.
+
+
+
+
+
+
+
+ Overall
+
+ Tally has real motion personality — but it's uneven . The
+ highest-frequency action, the check-off, is the most over-animated;
+ the add-habit sheet that should glide just snaps shut. Tighten the
+ frequent moments toward speed, finish the half-built transitions, then
+ spend delight where it's earned: the streaks.
+
+
+
+
+
+ 01
+ How each practitioner reads the motion
+
+ Three lenses, weighted for this context — a frequently-opened utility
+ where most motion should get out of the way, and a little should be
+ memorable. The read is what each would push on hardest today.
+
+
+
+
+ Lens
+ Verdict
+ One-line read
+
+
+
+
+
+ Restraint & Speed Emil Kowalski Secondary
+
+ Concern
+ The check-off and tab switches are over-animated for actions
+ this frequent — durations run long.
+
+
+
+
+ Production Polish Jakub Krehel Primary
+
+ Problem
+ Several transitions are half-built:
+ enters without exits , state changes that snap. Craft is
+ uneven.
+
+
+
+
+ Experimentation & Delight
+ Jhey Tompkins Selective
+
+ Strong
+ Restraint is mostly right. The open prize is making the streak
+ milestones actually feel earned.
+
+
+
+
+
+
+
+
+ 02
+ Where the timings land
+
+ Duration is a budget. A 320ms sheet is correct — a large surface earns
+ the time. A 600ms tab switch on an action you fire dozens of times a
+ session is the mistake. Each dot is one of Tally's animations, plotted
+ where it runs today.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0
+ 100
+ 300
+ 500
+ 600ms
+
+
+
+
+
+ INSTANT
+
+
+ RESPONSIVE
+
+
+ DELIBERATE
+
+
+ SLUGGISH
+
+
+
+
+
+ 5
+
+
+
+
+
+ 3
+
+ 7
+
+ 6
+
+ 4
+
+ 2
+
+ 1
+
+
+
+
+ fire most often
+
+
+
+
+
The animations
+
+
+ 1 Tab switch 600ms
+
+
+ 2 Check-off (bounce) 450ms
+
+
+ 3 Card hover lift 80ms
+
+
+ 4 Add-habit sheet enter 320ms
+
+
+ 5 Streak counter change none
+
+
+ 6 Page route 250ms
+
+
+ 7 Toast 200ms
+
+
+
+
+
+
+
+ Instant / Responsive · 0–300ms —
+ where almost everything belongs. Taps, toggles, tabs,
+ hovers.
+
+
+
+
+
+ Deliberate · 300–500ms —
+ earned by large surfaces: sheets, modals, full-screen
+ routes.
+
+
+
+
+
+ Sluggish · 500ms+ —
+ feels laggy. Reserve for rare, deliberately cinematic
+ moments — or nothing.
+
+
+
+
+
+
What's off
+
+ The two dots furthest right — tab switch (1) and check-off (2) —
+ are the actions that fire most. Frequency and duration are
+ inversely related: the more often it runs, the faster it should
+ be. And the streak counter (5) has no transition at all.
+
+
+
+
+
+
+
+ 03
+
+
Jakub Krehel — Production Polish
+ Primary lens
+
+
+ Problem
+
+
+
+
What's working well
+
+
+ ✓ Page routes use a clean opacity + 8px translate at 250ms — the
+ right shape and duration.
+ routes/transition.tsx:14
+
+
+ ✓ Toasts enter and exit symmetrically — the exit isn't
+ an afterthought. ui/Toast.tsx:31
+
+
+
+
Issues to address
+
+
+
+
+
+ Critical Jakub
+
+
+ The add-habit sheet enters, then snaps shut with no exit
+
+
+
+ What The bottom sheet animates up
+ on open (320ms, good), but on dismiss it's removed from the
+ tree instantly — no exit. The component renders
+ conditionally with no AnimatePresence wrapper,
+ so Framer Motion never gets to play the exit.
+
+
+ Why it matters A surface that
+ glides in and vanishes reads as broken — the eye
+ expects symmetry. It's the single most common "half-built
+ motion" tell, and it's on the app's primary create flow.
+
+
+
+ Recommended motion Wrap the
+ sheet in AnimatePresence and mirror the
+ enter: slide down + fade over 300ms with the same
+ ease-out-quint. The demo shows the enter; the
+ exit is its reverse.
+
+
+
+ screens/Habits/AddSheet.tsx:48
+
+
+
+
+
+
+
+
+
+ Sheet enter (mirror for exit) 300ms · ease-out-quint
+
+
+
+ Auto Light Dark
+
+
↻
+
+
+
+
+
+
+ New habit
+
+
+ Drink water
+ Add
+
+
+
+
+
+
+
+
+
+
+
+ Important Jakub
+
+
+ Streak counter jumps between values with no transition
+
+
+
+ What When a streak increments, the
+ number is replaced in place — a hard swap. There's no
+ transition on the value change, so the most rewarding number
+ in the app updates with the least ceremony.
+
+
+ Why it matters The streak count is
+ the payoff of the whole interaction. A snap makes a hard-won
+ number feel like a re-render, not an achievement.
+
+
+
+ Recommended motion Roll the new
+ value in: opacity + 10px translateY + a 5px blur that
+ clears, 220ms. Subtle, but it tells the eye
+ something changed and it's good .
+
+
+
+ components/StreakBadge.tsx:22
+
+
+
+
+
+
+
+
+
+ Number roll-in 220ms · opacity + Y + blur
+
+
+
+ Auto Light Dark
+
+
↻
+
+
+
+
+
+ Current streak
+
+
+ 7
+ days
+
+
+
+
+
+
+
+
Opportunities
+
+
+ 💡 Habit cards lean on a drop shadow that's invisible on the dark
+ theme — a 1px border would carry the elevation on both.
+ components/HabitCard.tsx:9
+
+
+
+
Through Jakub's lens
+
+ The vocabulary is right; the sentences are unfinished. Pair every
+ enter with an exit, give the streak its moment, and Tally crosses
+ from "animated" to "polished."
+
+
+
+
+
+ 04
+
+
Emil Kowalski — Restraint & Speed
+ Secondary lens
+
+
+ Concern
+
+
+
+
What's working well
+
+
+ ✓ Card hover lift is 80ms — instant, exactly right for a passive
+ affordance. components/HabitCard.tsx:18
+
+
+ ✓ No animation on keyboard-driven navigation — keyboard users
+ aren't taxed with motion they didn't ask for.
+
+
+
+
Issues to address
+
+
+
+
+
+ Critical Emil
+
+
+ Tab switches slide for 600ms — far too slow for the most
+ frequent action
+
+
+
+ What The four bottom tabs
+ cross-slide the full panel width over 600ms with an
+ ease-in-out. Tabs are the app's
+ highest-frequency navigation; a 600ms slide means every
+ switch holds the user behind an animation.
+
+
+ Why it matters Emil's rule: the
+ more often an action fires, the less it should animate. At
+ this duration the motion stops being feedback and becomes a
+ toll. ease-in-out also adds a slow start,
+ compounding the lag.
+
+
+
+ Recommended motion Drop to a
+ 180ms opacity crossfade with a 7px slide,
+ ease-out. Better still: consider no slide at
+ all — a fast crossfade is plenty of orientation for a tab.
+
+
+
navigation/TabView.tsx:63
+
+
+
+
+
+
+
+
+ Quick tab crossfade 180ms · ease-out
+
+
+
+ Auto Light Dark
+
+
↻
+
+
+
+
+
+ Today
+
+
+
+ Read 10 pages
+
+
+
+
+
+
+
+
+
+
+ Important Emil
+
+
+ Check-off pops from scale(0) with a spring bounce
+
+
+
+ What Ticking a habit animates the
+ checkmark from scale(0) with a bouncy spring
+ (~450ms to settle). It's the app's core, most-repeated
+ gesture, and it's the showiest animation in the product.
+
+
+ Why it matters Bounce on a
+ high-frequency confirm gets tiring fast — the overshoot
+ draws attention to motion the user has already mentally
+ completed. Starting from scale(0) exaggerates
+ the distance and the time.
+
+
+
+ Recommended motion Scale
+ 0.9 → 1 with opacity, 200ms
+ ease-out, no overshoot. Confident and done
+ before the finger lifts.
+
+
+
+ components/HabitCheck.tsx:27
+
+
+
+
+
+
+
+
+
+ Calm check, no bounce 200ms · ease-out
+
+
+
+ Auto Light Dark
+
+
↻
+
+
+
+
+
+
+
+
Through Emil's lens
+
+ Speed up everything the user touches constantly. The tab switch and
+ the check-off should feel instant; their current durations are the
+ difference between an app that feels fast and one that feels fussy.
+
+
+
+
+
+ 05
+
+
Jhey Tompkins — Experimentation & Delight
+ Selective lens
+
+
+ Strong
+
+
+
+
What's working well
+
+
+ ✓ Tally resists the urge to animate everything — restraint
+ is the right default for a daily utility. Delight is
+ rationed, which makes room for it to land where it counts.
+
+
+
+
Issues to address
+
+
+
+
+
+ Important Jhey
+
+
+ Hitting a milestone streak passes by with no celebration
+
+
+
+ What Crossing a 7-, 30-, or
+ 100-day streak looks identical to any other day — the number
+ just increments. The one moment in the app that has
+ genuinely earned a flourish gets none.
+
+
+ Why it matters This is where
+ delight pays for itself. A milestone is rare, emotionally
+ loaded, and shareable — exactly the place to spend motion
+ the rest of the app withholds. Skipping it leaves the payoff
+ flat.
+
+
+
+ Recommended motion On a
+ milestone only: a badge that scales
+ 0.8 → 1 (260ms ease-out) with a
+ short, one-shot sparkle burst. Fires once on the event —
+ not a looping pulse.
+
+
+
+ components/StreakBadge.tsx:40
+
+
+
+
+
+
+
+
+
+ Milestone badge enter 260ms · ease-out + sparkle
+
+
+
+ Auto Light Dark
+
+
↻
+
+
+
+
+
+
+
+
Opportunities
+
+
+ 💡 The today-list could stagger its rows in on first paint — 30ms
+ apart, opacity + 6px rise. One orchestrated load beats scattered
+ micro-interactions. screens/Today.tsx:51
+
+
+
+
Through Jhey's lens
+
+ Don't add more motion — add it in one right place. The
+ streak milestone is the moment worth engineering; everywhere else,
+ keeping your hands off the controls is the sophisticated move.
+
+
+
+
+
+ 06
+ In the order I'd fix them
+
+ Ordered by what users feel: critical (degrades the core loop
+ on every use) → important (real friction or a missed payoff)
+ → opportunity (could enhance).
+
+
+
+
+ Critical · must fix 2
+
+
+
+
+ Issue
+ File
+ Fix
+
+
+
+
+ Tab switch runs 600ms on the highest-frequency action
+ TabView.tsx:63180ms opacity crossfade + 7px slide, ease-out
+
+
+ Add-habit sheet has no exit — snaps shut
+ AddSheet.tsx:48Wrap in AnimatePresence; mirror the 300ms enter on exit
+
+
+
+
+
+ Important · should fix 3
+
+
+
+
+ Issue
+ File
+ Fix
+
+
+
+
+ Check-off pops from scale(0) with a bounce
+ HabitCheck.tsx:27scale 0.9→1 + opacity, 200ms ease-out, no overshoot
+
+
+ Streak counter swaps with no transition
+ StreakBadge.tsx:22220ms opacity + translateY + blur roll-in
+
+
+ Milestone streaks have no celebration moment
+ StreakBadge.tsx:40One-shot badge scale-in + sparkle, milestones only
+
+
+
+
+
+ Opportunities · could enhance 2
+
+
+
+
+ Enhancement
+ Where
+ Impact
+
+
+
+
+ Habit-card elevation invisible on dark theme
+ HabitCard.tsx:91px border carries elevation on both themes
+
+
+ Today-list could stagger in on first paint
+ Today.tsx:51
+ 30ms stagger, opacity + 6px rise — one orchestrated load
+
+
+
+
+
+
+
+
+ 07
+ Which lens carried this audit
+
+
Referenced most
+
Jakub Krehel — Production Polish
+
+ Tally's gaps are craft gaps, not taste gaps: enters without exits,
+ state changes that snap. That's Jakub's territory — finishing what's
+ been started — so his lens drove the ordering. Emil set the
+ durations; Jhey marked the one place to spend.
+
+
+
+ Lean Emil Treat every duration as a budget. Push tab, check, and toggle
+ timings under 200ms and question any motion on a high-frequency
+ action.
+
+
+ Lean Jakub Audit every conditional render for a missing exit. Pair enters
+ and exits, and give meaningful state changes a transition.
+
+
+ Lean Jhey Pick the single highest-emotion moment — the milestone — and
+ over-invest there, with @property, springs, or scroll-driven
+ touches.
+
+
+
+
+
+ Tally motion audit · design-motion-principles
+ 7 findings · 2 critical · 3 important · 2 opportunities
+
+