App animation & motion

<context>
I need a motion spec, then code, for one interaction in my app: [interaction, e.g. tapping a product card opens its detail page].
Stack: [stack: CSS | Web Animations API | View Transitions API | Motion for React | SwiftUI | Jetpack Compose].
I am not a motion designer.
</context>
 
<task>
Interview me first: ask the questions a motion designer asks before writing a motion spec.
</task>
 
<requirements>
- At most 10 questions, grouped under: the state change, purpose, frequency and context, gestures and interruption, accessibility, the existing motion system.
- For each question: why it matters to the spec, and 2-3 typical answers I can pick from.
- Do not propose any motion, numbers or code yet.
</requirements>
 
<process>
Ask the questions, then stop and wait for my answers.
</process>

<materials>
[paste the interview questions and my answers]
</materials>
 
<task>
Propose 2-4 materially different motion approaches for this interaction, e.g. a container transform, a shared-element transition, a shared axis or a fade through.
</task>
 
<requirements>
- For each: the pattern by name, the lead element, a duration range and easing family, what it explains to the user (orientation, continuity, hierarchy), the effort to build it on my stack, its performance risk on a low-end phone, and its reduced-motion version.
- Say which Material 3 transition pattern or Apple Human Interface Guidelines convention each follows, and where it departs from it.
- Recommend one and say what would make you pick another.
</requirements>
 
<process>
Give the options as a table, then the recommendation, then stop and wait for my choice. Do not write the spec yet.
</process>

<materials>
Motion tokens: [paste, e.g. durations 150/250/400 ms; standard easing cubic-bezier(0.2, 0, 0, 1)]
Interview answers and the option I chose: [paste]
</materials>
 
<context>
Interaction: [interaction, e.g. tapping a product card in a grid opens its detail page]
Purpose: [purpose: feedback | orientation | continuity | hierarchy | status | delight]
Chosen pattern: [pattern: container transform | shared element | shared axis | fade through | crossfade]
Stack: [stack: CSS | Web Animations API | View Transitions API | Motion for React | SwiftUI | Jetpack Compose]
Frequency: [frequency: dozens of times a day | a few times a day | once per session | rarely]
The spec goes to engineers who will implement it exactly as written.
</context>
 
<examples>
[optional: 1-2 interactions in other apps whose motion you like and why, e.g. "a gallery app's zoom into a photo: quick, no bounce, I never lose my place"; 1 you don't, e.g. "our current modal: 600 ms and floaty"]
</examples>
 
<task>
A motion spec for this interaction, then production code that implements it, so engineers can build it without guessing numbers.
</task>
 
<requirements>
- Durations within the usual ranges (feedback 50-150 ms, menus 150-250 ms, dialogs and sheets 250-400 ms, screens 300-500 ms); justify anything outside them.
- Easing by direction: entering elements decelerate, leaving elements accelerate, on-screen moves use standard easing. Give exact cubic-bezier values or spring parameters (damping ratio and stiffness), using my tokens where they exist.
- The exit is faster than the entry, not the same animation reversed.
- Animate only transform and opacity unless you justify the exception; never scale from 0.
- Interruptible: a tap or swipe mid-transition reverses from the current position and velocity.
- Holds 60 fps on [devices, e.g. a 3-year-old mid-range Android phone].
- Focus moves immediately, input is never blocked, and the end state is correct even if the animation never runs.
- Reduced motion (prefers-reduced-motion on the web, Reduce Motion on iOS, Remove animations on Android): replace movement with a short crossfade or an instant change; keep feedback.
- Name the Material 3 pattern or Apple HIG convention you follow and where you depart from it.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing, and [CHECK DOCS] next to any API you are not sure exists in the current version.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every animated element serves the stated purpose; anything that doesn't is cut.
- One lead element; the others follow it; any stagger is capped at about 300 ms in total.
- Every row has a duration, a delay and an easing or spring in numbers; no "smooth" or "snappy" without them.
- The code matches the spec table value for value, including the reduced-motion path and when focus moves.
- Nothing in the code animates width, height, top, left, margin or a large blur.
</quality_bar>
 
<output_format>
1. A spec table: element | property | from | to | duration (ms) | delay (ms) | easing or spring | notes.
2. The choreography in one sentence, and how the reverse transition differs in one sentence.
3. Interruption, focus and reduced-motion rules as bullets, with the reduced-motion replacement for each row.
4. The code in one self-contained file.
5. The assumptions.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
Write the spec table first and check it against the quality bar before writing any code.
</process>

<materials>
The brief: [paste the stage 3 prompt]
The spec and code: [paste]
</materials>
 
<context>
This is a fresh chat. The spec below was written in another conversation; review it as someone seeing it for the first time, before it goes to engineering.
</context>
 
<task>
A review of this motion spec and its code. Do not rewrite them.
</task>
 
<requirements>
- Judge against: purpose, duration ranges, easing direction, choreography, interruption, performance (transform and opacity only), reduced motion, consistency with the tokens, accessibility (focus, input, flashing; WCAG 2.2.2, 2.3.1 and 2.3.3), and a correct end state without the animation.
- Walk through it three times: as a user with reduced motion on, as a keyboard user, and on a slow phone that drops frames. Say what breaks in each.
- Compare the code with the spec table row by row.
- Quote the row or line behind every finding.
</requirements>
 
<quality_bar>
Before answering, check that every finding names a criterion, cites a row or line, and gives a fix in numbers or code terms.
</quality_bar>
 
<output_format>
A table: rank | finding | criterion | where | fix, most severe first. Then one line: ship, fix first, or redo.
</output_format>
 
<process>
Rank the issues by impact on users; do not produce a revised spec or code.
</process>

Create motion tokens for [product, e.g. a calm budgeting app] on [stack: CSS | Motion for React | SwiftUI | Jetpack Compose]: 5-7 durations in ms, easings as cubic-bezier (standard, decelerate, accelerate, one emphasized pair), 3 spatial springs and 1 effects spring, and which token to use for press, menus, dialogs, sheets and page transitions.
Base the ranges on Material 3 and NN/g, and check that frequent actions stay under about 200 ms.

<materials>
[optional: paste the animation values the app uses today, or a list of its animations]
</materials>
 
<context>
Product: [product, e.g. a budgeting app for freelancers]
Personality: [personality: calm and precise | brisk and efficient | playful | expressive]
Platforms: [platforms, e.g. web with CSS and Motion for React; iOS with SwiftUI]
The tokens will be used by [team, e.g. 3 engineers and no motion designer].
</context>
 
<examples>
[optional: 1-3 apps whose motion feels right for us and why, e.g. "fast, never bounces, things leave quicker than they arrive"; 1 that feels wrong, and why]
</examples>
 
<task>
A set of motion tokens with usage rules, so every component animates from the same values.
</task>
 
<requirements>
- Duration tokens: 5-7 steps in ms, each with what it is for.
- Easing tokens as cubic-bezier values: standard, enter (decelerate), exit (accelerate), and one emphasized pair.
- Spring tokens: 3 spatial (fast, default, slow) and 1 effects spring with no overshoot, as damping ratio and stiffness, plus the equivalent in each of my platforms' own parameters.
- Usage rules: which tokens for press feedback, menus, dialogs, sheets, page transitions and staggers.
- A reduced-motion rule for each category.
- Base the ranges on Material 3's motion tokens and NN/g's duration guidance, and say where you deviate and why.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Frequent actions (press, toggle, menu) stay at or under about 200 ms.
- Every exit token is shorter than its matching enter token.
- No effects token (color, opacity) overshoots.
- The personality shows in the numbers (bounce, duration), not in adjectives.
</quality_bar>
 
<output_format>
Tables for durations, easings and springs (name | value | use for), the usage rules as a table, then the tokens as CSS custom properties, plus a constants file for each native platform I listed.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
</process>

Spec and code a press micro-interaction for [component, e.g. the primary button] in [stack: CSS | Motion for React | SwiftUI | Jetpack Compose]: scale to about 0.97 in about 100 ms, spring back with no visible bounce, the same pressed state on Space and Enter, color change only under reduced motion.
Check that feedback starts within 100 ms and the action never waits for the animation.

<materials>
Tokens: [paste, or write "none yet"]
</materials>
 
<context>
Component: [component: primary button | toggle | favorite or like | checkbox | add to cart]
What it confirms: [result, e.g. "added to favorites", saved optimistically before the server answers]
Stack: [stack: CSS | Motion for React | SwiftUI | Jetpack Compose]
Frequency: [frequency: dozens of times a day | a few times a day | rarely]
</context>
 
<examples>
[optional: a micro-interaction you like and why, e.g. "a like that fills and settles in under 200 ms"; one you don't, e.g. "a 600 ms bounce on every tap"]
</examples>
 
<task>
A micro-interaction spec and code for this component: rest, hover, pressed, success, failure and disabled states.
</task>
 
<requirements>
- Press feedback within about 100 ms: a slight scale (about 0.97) or one color step; never scale from 0.
- Release springs back with no visible overshoot; a success state may overshoot once, on spatial properties only.
- Hover only on devices that support it (@media (hover: hover)); the same pressed state on Space and Enter.
- Optimistic: show the result at once and animate a rollback if the request fails.
- Reduced motion: color or opacity change only; keep the feedback.
- Animate only transform and opacity.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- It still feels instant on the 50th press, not just the first.
- The action never waits for the animation to finish.
- Every state has a duration and an easing or spring in numbers.
</quality_bar>
 
<output_format>
A spec table (state | property | from | to | duration | easing or spring), then the code.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
</process>

Storyboard the transition from [screen A, e.g. the inbox] to [screen B, e.g. one message] and back as 6-8 key frames each way: timestamp (ms), what's on screen, what moves and which way, and where the eye should be.
Flag any frame where two things compete for attention.

<materials>
[paste or describe both screens: layout and main elements]
</materials>
 
<context>
Screens: from [screen A, e.g. the inbox list] to [screen B, e.g. one message], and back.
User and moment: [user, e.g. a commuter on a phone, one hand, going back and forth often]
Pattern so far: [pattern: container transform | shared element | shared axis | fade through | not decided]
The storyboard is for [readers, e.g. a designer who will animate it and a product lead who must approve it].
</context>
 
<task>
A storyboard of the transition in both directions, so it can be reviewed before it is built.
</task>
 
<requirements>
- 6-8 key frames per direction, each with a timestamp (ms), what is on screen, what is moving and in which direction, and where the eye should be.
- One lead element; say when each other element starts relative to it.
- Keep to the usual range for screen transitions (about 300-500 ms) and name the easing for each movement.
- Then narrate the same transition at 10% speed, as if describing a slow-motion recording.
- Describe the reduced-motion version in one line.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- At every frame there is one obvious place to look.
- Spatial logic holds: forward and back move in opposite directions, and things leave toward where they live.
- The back transition is shorter than the forward one.
- Nothing slides or zooms across the full screen without a reason the user would notice.
</quality_bar>
 
<output_format>
A table per direction (frame | ms | on screen | moving | eye on), the slow-motion narration in under 150 words, the reduced-motion line, then the assumptions.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
</process>

Implement a bottom sheet in [stack: Motion for React | SwiftUI | Jetpack Compose] with snap points at [snap points, e.g. 40% and 90% of screen height]: it follows the finger 1:1, rubber-bands past the top, settles with a spring that carries the release velocity, and dismisses past [threshold, e.g. 30% down or a fast fling].
Add a close button as the non-drag alternative, and check that a new touch catches it mid-flight.

<context>
Component: [component: bottom sheet | side drawer | swipeable card | carousel]
Stack: [stack: Motion for React | SwiftUI | Jetpack Compose | UIKit]
Snap points: [snap points, e.g. 40% and 90% of screen height]
Dismiss rule: [rule, e.g. dragged past 30% down, or flung down fast]
Frequency: [frequency: dozens of times a day | a few times a day | rarely]
</context>
 
<task>
A gesture-driven version of this component, with a behavior spec and code: drag, release, snap, dismiss and interruption.
</task>
 
<requirements>
- While dragging: direct manipulation; the element tracks the finger exactly, with no easing.
- Rubber banding past the outermost snap point, with increasing resistance.
- On release: pick the snap point from position plus velocity; a spring (damping ratio about 0.85) starts with the release velocity.
- Interruptible: a new touch catches the element mid-animation.
- The backdrop's opacity tracks the position.
- A tap or button alternative for every drag (WCAG 2.5.7 Dragging Movements).
- Reduced motion: no overshoot and a shorter settle; the gesture still works.
- Spring parameters in the platform's own terms: [spring parameters: dampingRatio and stiffness | duration and bounce | stiffness, damping and mass].
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing, and [CHECK DOCS] next to any API you are not sure exists in the current version.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- A slow drag and a fast fling from the same position can land on different snap points.
- Nothing jumps when the finger lifts: the spring starts from the current position and speed.
- The non-drag alternative reaches every snap point.
- Only transform and opacity animate.
</quality_bar>
 
<output_format>
A behavior table (phase | rule | numbers), one self-contained code example, then what to test on a real device.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
</process>

Design the loading state for [screen, e.g. the order history list]: a skeleton that matches the final layout exactly, a slow low-contrast shimmer (static under reduced motion), nothing at all if data arrives within about 300 ms, then a 150 ms crossfade or a 30 ms stagger capped at 6 items.
Check that nothing shifts when the content lands.

<materials>
[paste the screen's layout or component code]
</materials>
 
<context>
Screen: [screen, e.g. the order history list, up to 50 items]
Typical wait: [wait: under 1 s | 1-10 s | over 10 s | varies a lot]
Stack: [stack: CSS | Motion for React | SwiftUI | Jetpack Compose]
</context>
 
<task>
The loading and arrival motion for this screen: what shows while waiting, and how the content enters when it arrives.
</task>
 
<requirements>
- Match the indicator to the wait, following NN/g: nothing under about 1 s, a skeleton for full-page loads up to about 10 s, a determinate progress bar with an estimate beyond that.
- Skeleton: the same heights and positions as the final layout; a slow, subtle shimmer about every 1.5 s.
- Don't show the skeleton at all if data arrives within about 300 ms.
- Arrival: a 150 ms crossfade, or items fade in and rise 8 px over 200 ms with a 30 ms stagger for the first 6 visible items; the rest appear with the sixth.
- Never re-run the entrance on re-render, filtering or pagination.
- Reduced motion: a static skeleton and a single short fade on arrival.
- Mark the region aria-busy while loading.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Nothing moves or resizes when content replaces the skeleton (no layout shift).
- The whole entrance is finished within about 350 ms.
- A fast connection never sees a flash of skeleton.
</quality_bar>
 
<output_format>
A short spec table, the code, then how you stop the entrance from re-running.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
</process>

Write a brief for a [format: Lottie | Rive] animation of [subject, e.g. an empty-inbox illustration]: size, frame rate, duration, loop or play once, the segments or states the app triggers, a file-size budget, and the still frame for reduced motion.
Check that every state the app needs is named.

<materials>
[paste the palette and illustration style rules]
</materials>
 
<context>
Where it appears: [placement, e.g. the inbox empty state, 240 x 240 px on mobile]
What it should do: [purpose: feedback | status | delight | onboarding]
Format: [format: Lottie | Rive]
Behavior: [behavior: plays once | loops | segments triggered by the app | a state machine reacting to input]
Platforms: [platforms, e.g. web, iOS and Android]
</context>
 
<examples>
[1-3 animations you like and why, e.g. "a checkmark that draws in, then settles, in under 1 s"; 1 you don't, and why]
</examples>
 
<task>
A brief an animator can work from and an engineer can integrate against, for this animation.
</task>
 
<requirements>
- Specs: artboard size, frame rate, duration, loop or play once, and either the named segments (Lottie) or the state machine's inputs and states (Rive) the app will trigger.
- Motion direction in plain words and numbers: easing family, amount of overshoot, and which principles carry the feel (anticipation, follow-through, squash and stretch).
- Performance: a file-size budget, a layer limit, no features the target players don't support (check the player's supported-features list), and a test on a low-end phone.
- Reduced motion: the still frame to show, and whether it may play once on request.
- Anything that loops for more than 5 seconds needs a pause control (WCAG 2.2.2); nothing flashes more than 3 times a second (2.3.1).
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- An animator could start without asking a question, and the engineer knows exactly which segments or inputs to call.
- Every state the app needs (idle, hover, pressed, success, error, loading) is named or explicitly ruled out.
- The motion direction uses numbers, not "fun" or "smooth".
</quality_bar>
 
<output_format>
A one-page brief: purpose, a specs table, a states or segments table (name | trigger | frames or behavior), motion direction, performance budget, accessibility, deliverables (source file, exported file, still frame).
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on.
</process>

Our [component, e.g. sheet-open] animation uses [values, e.g. 400 ms, cubic-bezier(0.4, 0, 0.2, 1)]. It should feel [direction: snappier | heavier | calmer | more playful].
Give 3 variants, each with duration or spring parameters and one sentence on how it will feel; no overshoot on color or opacity. Stop after the options.

<materials>
Current values: [paste, e.g. 400 ms, cubic-bezier(0.4, 0, 0.2, 1), or the code]
Tokens: [paste, or write "none"]
</materials>
 
<context>
Component: [component, e.g. the bottom sheet opening]
Feedback we got: [quote, e.g. "it feels sluggish"]
Direction: [direction: snappier | heavier | calmer | more playful | more premium]
Stack: [stack: CSS | Motion for React | SwiftUI | Jetpack Compose]
</context>
 
<examples>
[optional: 1-2 interactions that already have the feel we want and why; 1 that goes too far]
</examples>
 
<task>
Three variants that move this animation in the requested direction, so we can try them side by side and pick one.
</task>
 
<requirements>
- Each variant: duration and easing, or spring parameters as damping ratio and stiffness, plus the equivalent in my stack's own parameters.
- Vary them materially, e.g. a shorter duration, a different curve, a spring with slight overshoot.
- One sentence each on how it will feel different and what it costs (overshoot reads as playful but distracts on frequent actions).
- No overshoot on color or opacity; stay inside our tokens or say which new token a variant needs.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The three variants would look different side by side, not 10 ms apart.
- Each one stays inside the duration range for this kind of motion.
- The recommendation says what to test it against, e.g. the 50th repetition and a low-end phone.
</quality_bar>
 
<output_format>
A table: variant | values | stack equivalent | how it feels | risk. Then a recommendation in two sentences.
</output_format>
 
<process>
Give the options and the recommendation, then stop and wait for my choice before writing any code.
</process>

Audit the motion in this [input: code | screen recording described frame by frame | list of animations]: for each animation, its duration, easing, purpose and problems (too long, wrong easing direction, layout properties animated, not interruptible, no reduced-motion path). Rate severity 1-3, list the top 5 fixes, and don't rewrite anything.
[paste]

<materials>
[paste the code, or describe the screen recording frame by frame with timestamps]
</materials>
 
<context>
App: [app, e.g. a React web app using Motion, used all day by support agents]
Complaint: [complaint: feels slow | janky on some devices | inconsistent between screens | an accessibility complaint]
Target devices: [devices, e.g. mid-range Android phones and 5-year-old laptops]
</context>
 
<task>
A motion audit of this app, covering purpose, performance, accessibility and consistency. Do not rewrite the code.
</task>
 
<requirements>
- For each animation: what animates, its duration and easing, its purpose (feedback, orientation, continuity, hierarchy, status, delight or none), and its problems.
- Check: durations against the usual ranges; easing direction; linear movement; layout properties animated (width, height, top, left, margin); large blurs or shadows; will-change left on permanently; animations that can't be interrupted; competing movements; focus or input blocked during animation.
- Accessibility: a reduced-motion path for each animation; anything moving on its own for more than 5 seconds without a pause (WCAG 2.2.2); anything that could flash more than 3 times a second (2.3.1); parallax, zooms or large slides (vestibular triggers); drags without a tap alternative (2.5.7).
- Quote the line or timestamp behind every finding.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every finding names the rule it breaks and where.
- Severity reflects frequency: a slow animation on a frequent action outranks a slow one on a rare screen.
- The fixes converge on one shared set of tokens, not a new value per component.
</quality_bar>
 
<output_format>
A table: issue | where | rule (WCAG criterion, performance or guideline) | severity 1-3 | fix. Then the top 5 changes by impact, and a proposed shared token set in one short table.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on. List the fixes; don't apply them.
</process>

Make the modal animate nicely.

<materials>
Motion tokens: durations 150 / 250 / 400 ms; enter easing cubic-bezier(0, 0, 0, 1); exit easing cubic-bezier(0.3, 0, 1, 1).
</materials>
 
<context>
A confirmation dialog in a React app using Motion for React. Trigger: the user clicks "Delete project". Power users see it several times a day, so it must feel quick.
Purpose: focus attention on the decision and show that the dialog sits above the page.
</context>
 
<task>
The open and close motion for this dialog: a spec table, then the component code.
</task>
 
<requirements>
- Open: the backdrop fades in; the dialog fades in and scales from 0.96 to 1, never from 0. Close: faster than open.
- Transform and opacity only.
- Focus moves into the dialog as soon as it opens, not when the animation ends; Esc and a backdrop click close it; closing mid-open reverses smoothly from where it is.
- Reduced motion: opacity only, 150 ms.
- Never invent numbers, names, quotes or sources: write [NEEDS SOURCE] where support is missing, and [CHECK DOCS] next to any Motion API you are not sure exists.
- End with a list of the assumptions you made.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Durations fit a frequent dialog: open about 250 ms or less, close shorter.
- Enter decelerates, exit accelerates.
- The code matches the spec table value for value, including when focus moves and the reduced-motion path.
</quality_bar>
 
<output_format>
A spec table (element | property | from | to | duration | delay | easing), then one component file.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change your answer; otherwise go on. Write the spec first and check it against the quality bar before writing code.
</process>

element   property  from   to    duration  delay  easing
backdrop  opacity   0      1     250 ms    0      cubic-bezier(0, 0, 0, 1)
dialog    opacity   0      1     250 ms    0      cubic-bezier(0, 0, 0, 1)
dialog    scale     0.96   1     250 ms    0      cubic-bezier(0, 0, 0, 1)
close     all rows reversed      150 ms    0      cubic-bezier(0.3, 0, 1, 1)
Reduced motion: opacity only, 150 ms. Focus: moves to Cancel on open.
 
<motion.div role="alertdialog" aria-modal="true"
  initial={{ opacity: 0, scale: reduce ? 1 : 0.96 }}
  animate={{ opacity: 1, scale: 1 }}
  exit={{ opacity: 0, scale: reduce ? 1 : 0.96,
          transition: { duration: 0.15, ease: [0.3, 0, 1, 1] } }}
  transition={{ duration: reduce ? 0.15 : 0.25, ease: [0, 0, 0, 1] }}
  onAnimationComplete={() => cancelRef.current?.focus()}>
…
Assumptions: Cancel is the safer default focus; the backdrop is a sibling motion.div inside AnimatePresence.

The spec says focus moves into the dialog on open, but the code focuses Cancel in onAnimationComplete, which runs 250 ms later. Fix only that: move focus to Cancel as soon as the dialog mounts, return focus to the "Delete project" button on close, and leave every motion value unchanged. Then show a test that presses Esc 100 ms after opening and checks that the dialog reverses from where it is and focus returns to the button.

Check your spec against these ranges: feedback 50-150 ms,
menus 150-250 ms, dialogs and sheets 250-400 ms, screens
300-500 ms. Flag anything outside them and justify or fix it.
Then list every property you animate that isn't transform or
opacity.