Sign InGet Started

Adding Motion and Interaction Taste Rules for Premium Frontend UI

Teaches you how to specify animation timing, easing curves, hover states, and transition guidelines inside SKILL.md files so AI coding agents produce interfaces that feel polished and intentional rather than static or gratuitously animated.

Define explicit animation duration ranges (150-300ms for micro-interactions, 300-500ms for layout transitions), specify named easing curves (ease-out for enters, ease-in for exits), document hover/focus/active state behaviors with exact property changes, and set transition property allowlists. Place these rules in a dedicated motion section of your SKILL.md file so AI agents apply them consistently instead of generating default or random animation values.

Outcome: Your SKILL.md file contains a complete, enforceable motion and interaction section that causes AI coding agents to generate interfaces with consistent, purposeful animations, correct easing curves, and well-defined interactive states instead of defaults or missing transitions.

Synthesized from public framework references and reviewed for accuracy.

DevelopmentIntermediate45-90 minutes

Prerequisites

  • Basic understanding of CSS transitions and animations (properties, durations, easing functions)
  • Familiarity with the SKILL.md file format and how AI coding agents consume instruction files
  • Working knowledge of interactive states in CSS (hover, focus, active, disabled)
  • Experience with at least one AI coding agent such as Cursor, Claude Code, or v0

Overview

Motion is the layer of frontend design that separates polished products from prototypes. When an AI coding agent generates a button, it rarely adds a hover transition. When it builds a modal, it usually hard-cuts it into view with no entrance animation. When it creates a dropdown, the easing curve is either missing or set to the CSS default ease, which looks mushy and unintentional. This premium frontend UI skill teaches you to write explicit motion and interaction rules inside SKILL.md files so that every AI-generated component ships with purposeful, branded animation behavior.

Within the Taste Skill Frontend Design Framework, motion rules sit alongside typography, spacing, layout density, and anti-slop review constraints. They are the last mile of perceived quality. A user may not consciously notice that a tooltip fades in over 150ms with ease-out, but they will notice when it pops in with zero transition or lurches in over 800ms with linear easing. The goal of this skill is to make the "right" motion behavior the default output of your AI agent, not something you patch after generation.

The concrete artifact you produce is a motion and interaction section inside your SKILL.md file. This section typically covers four areas: duration ranges bucketed by interaction type, named easing curves mapped to motion categories, interactive state specifications for hover, focus, active, and disabled, and a transition property allowlist that prevents AI agents from animating properties that cause layout thrash (like width, height, or top). Once this section exists, every component the agent generates will reference these constraints, producing consistent motion across your entire interface. The section is portable: you can copy it between projects, share it with teammates, or publish it as part of an open-source design system SKILL.md file.

How It Works

Motion taste rules work by replacing the AI agent's implicit defaults with explicit, bounded constraints. Without rules, an AI agent generating a CSS transition will pick from its training distribution, which is heavily biased toward tutorial-grade code: transition: all 0.3s ease. That single line contains three problems. First, all means every CSS property is animated, including layout properties that trigger expensive reflows. Second, 0.3s is a generic middle-ground duration that is too slow for a color change and too fast for a page transition. Third, ease is a compromise curve that feels soft and directionless.

The mental model behind motion rules is constraint-based generation. You are not scripting every animation. You are defining the boundaries and categories so the agent can make correct local decisions. Think of it like a type system for motion: you define the valid types (micro, standard, macro), the valid values within each type (duration ranges, easing names), and the invalid patterns (animating layout properties, durations over 500ms for in-page interactions). The agent then operates freely within those bounds.

Easing curves deserve special attention because they carry emotional weight. ease-out (fast start, slow finish) feels responsive and confident, making it ideal for elements entering the viewport. ease-in (slow start, fast exit) feels like departure, making it right for elements leaving. ease-in-out works for elements that move from one position to another without entering or leaving. linear is almost never correct for UI motion because organic objects do not move at constant speed. Your SKILL.md should name these mappings explicitly so the agent does not guess.

Interactive states (hover, focus, active, disabled) are the other half of the motion equation. These are not animations in the keyframe sense, but they involve transitions, and they deeply affect perceived quality. A button with no hover state feels dead. A button with a hover state that changes background-color but does not transition feels jarring. A button whose focus ring appears with no transition feels mechanical. Your rules should specify which properties change per state and over what duration. Most hover transitions should complete in 100-200ms. Focus rings should appear instantly (0ms delay) for accessibility but can fade in over 100ms for visual smoothness.

This skill connects to other parts of the Taste Skill Frontend Design Framework at several points. Your typography and spacing rules determine the visual resting state that motion departs from and returns to. Your layout density constraints determine how much space is available for motion to occupy. Your anti-slop review rules should include motion checks as pass/fail criteria. Writing motion rules in isolation will produce technically correct but contextually disconnected animations.

Step-by-Step

  1. Step 1: Audit your current AI-generated motion output

    md if you are starting fresh). Good candidates include a button, a modal/dialog, a dropdown menu, a tooltip, a notification toast, a sidebar navigation, and a card with hover effects. For each generated component, document the motion behavior: does it have transitions? What are the durations and easing curves?

    Which interactive states are handled? Record this in a simple table with columns for component, transition present (yes/no), duration, easing, and states handled. This baseline tells you exactly which gaps your motion rules need to fill. 3s ease` on everything.

    Tip: Run this audit twice with the same prompts. AI agents are non-deterministic, so if a component gets correct motion on one run and wrong motion on the next, that means the behavior is not constrained, just lucky. Only consistent behavior counts as covered.

  2. Step 2: Define duration buckets by interaction category

    Create three to four duration categories that cover the full range of UI motion. A proven starting structure is: micro (100-150ms) for color changes, opacity shifts, and icon state changes; standard (200-300ms) for component-level transitions like dropdowns opening, tooltips appearing, and accordion expansion; macro (300-500ms) for layout-level transitions like modals entering, sidebars sliding, and page transitions; and decorative (500-1000ms) for loading skeletons, progress indicators, and background ambient motion. Write each bucket as a named category in your SKILL.md with the allowed range, the types of interactions it applies to, and explicit examples. Include a hard ceiling rule: no UI transition should exceed 500ms unless it is decorative or page-level, and no decorative animation should exceed 1000ms.

    Tip: If you are unsure about a duration, lean shorter. Users perceive 200ms as instant and 400ms as deliberate. Anything above 500ms feels sluggish for interactive elements. Test by adding a `transition-duration` of your candidate value to a button hover and clicking it 20 times rapidly. If it feels like it is lagging behind your clicks, it is too slow.

  3. Step 3: Map easing curves to motion intent

    Define a named set of easing curves and specify when each one applies. At minimum, define three: an enter curve (elements appearing or expanding), an exit curve (elements disappearing or collapsing), and a move curve (elements repositioning without entering or leaving). 2, 1)or the CSS keywordease-out. 0, 1, 1) or ease-in.

    2, 1)orease-in-out. md so the agent uses variable names like --ease-enterinstead of raw cubic-bezier values. Include a rule thatlinearis only valid for progress bars and continuous indicators, never for interactive element transitions. Explicitly banease` (the CSS default keyword) because its curve is ambiguous and does not communicate intent.

    Tip: Material Design, Apple HIG, and Vercel's Geist all publish their easing curves. If your product already follows one of these systems, use their curves directly and cite them in your SKILL.md. This gives the AI agent training-data reinforcement because it has likely seen those curves in context before.

  4. Step 4: Specify interactive state rules for common elements

    md that covers the five core interactive states: default, hover, focus, active (pressed), and disabled. For each state, specify which CSS properties are allowed to change and what the transition duration should be. 5 with pointer-events: none and no transition. Repeat this pattern for links, cards, form inputs, and navigation items.

    Be explicit about which properties are NOT allowed to change on hover. For example, elements should not change font-size, padding, or width on hover because those cause layout shifts.

    Tip: Focus states deserve extra care. Never remove the focus indicator. If you want a custom focus ring instead of the browser default, specify it as a `box-shadow` rather than an `outline` so it respects border-radius. Always ensure the focus state meets WCAG 2.1 contrast requirements (3:1 minimum against adjacent colors).

  5. Step 5: Create a transition property allowlist

    Write an explicit list of CSS properties that the AI agent is allowed to animate with transitions. This is a safeguard against the transition: all anti-pattern. The allowlist should include: opacity, transform, background-color, color, border-color, box-shadow, and filter. These properties are either compositor-friendly (opacity, transform) or paint-only (colors, shadows), meaning they do not trigger layout recalculation.

    Explicitly ban transitions on width, height, top, left, right, bottom, margin, padding, font-size, and border-width. These cause layout thrash and produce janky animations, especially on lower-powered devices. Write this as a hard rule with the reasoning included so the AI agent understands the constraint, not just the list.

    Tip: If a design requires animating size, instruct the agent to use `transform: scale()` instead of `width`/`height`. If it requires animating position, use `transform: translate()` instead of `top`/`left`. These compositor-friendly alternatives are visually identical but perform dramatically better.

  6. Step 6: Write reduced-motion override rules

    Accessibility requires that all motion respects the prefers-reduced-motion media query. md that instructs the AI agent to wrap all transitions and animations in a reduced-motion check. The rule should state: when prefers-reduced-motion: reduce is active, all transition durations must be set to 0ms or replaced with instant opacity fades (no transforms, no slides, no scaling). This is not optional.

    Include specific code guidance: the agent should use @media (prefers-reduced-motion: reduce) to override motion, not remove transitions entirely, so that state changes still occur visually but without animation. Opacity crossfades at 0ms are acceptable because they communicate state change without motion.

    Tip: Test your reduced-motion rules by enabling the setting in your OS (macOS: System Settings > Accessibility > Display > Reduce motion; Windows: Settings > Ease of Access > Display > Show animations). Every interactive element should still visually communicate state changes, just without movement.

  7. Step 7: Add motion examples as inline code blocks in your SKILL.md

    AI agents perform better with concrete examples than with abstract rules alone. md showing the correct implementation. For example, include a button component showing the hover transition with the correct property list, duration, and easing variable. Include a modal showing the entrance animation with the correct keyframe and duration.

    Include a tooltip showing the fade-in with the correct delay and easing. Label each example with the rule it demonstrates. Three to five inline code examples are sufficient. md becoming bloated.

    Tip: Place the code examples immediately after the rules they illustrate, not in a separate examples section at the bottom. AI agents process SKILL.md files sequentially, and proximity between rule and example increases the chance the agent will apply the pattern correctly.

  8. Step 8: Validate by regenerating your audit components

    Return to the 5-8 components you generated in Step 1. md loaded into your AI agent. Compare the output against your motion rules: does the button use the correct easing? Does the modal entrance animation fall within the macro duration range?

    Does the tooltip use the property allowlist instead of transition: all? Does the dropdown respect reduced-motion? Score each component pass/fail against your rules. md for clarity.

    The most common cause of agent non-compliance is ambiguous phrasing. " Run the regeneration twice to confirm consistency.

    Tip: If a component passes on the first generation but fails on the second, the rule is probably present but not strongly enough stated. Promote it from a recommendation to a hard requirement using imperative language: 'always,' 'never,' 'must,' rather than 'prefer,' 'try to,' 'should.'

Examples

Example: SaaS dashboard with sidebar navigation and modals

A two-person startup is building a B2B analytics dashboard using Cursor with Claude as the AI agent. The interface has a collapsible sidebar, data cards with hover states, and confirmation modals. The team noticed that Cursor generates static components with no transitions, and when transitions are present, they use `transition: all 0.3s ease`. The team has 45 minutes to add motion rules to their existing SKILL.md.

The team starts by generating their sidebar, a data card, and a modal without motion rules and confirms the baseline: no hover transitions on cards, no sidebar slide animation, and the modal hard-cuts into view. md defining three duration buckets: micro (100-150ms) for card hover color changes, standard (250ms) for sidebar collapse/expand, and macro (350ms) for modal entrance. 4, 0, 1, 1)for sidebar collapse and modal dismissal. They add an allowlist restricting transitions toopacity, transform, background-color, color, and box-shadow`.

They include a reduced-motion override block. They add two inline code examples: one showing the card hover pattern and one showing the modal entrance keyframe. After regenerating all three components, the sidebar slides with correct easing, cards have a subtle hover background transition at 150ms, and the modal fades up over 350ms. The reduced-motion test confirms all motion collapses to instant state changes.

Example: E-commerce product page for a solo developer

A solo developer is building a direct-to-consumer product page using v0. The page has a product image gallery with thumbnails, an add-to-cart button, a size selector dropdown, and a notification toast that confirms the item was added. The developer wants the page to feel premium but is worried about over-animating. They have no existing SKILL.md and are starting from scratch.

md and writes the motion section first because motion is their primary quality concern. They define only two duration buckets to keep things simple: micro (120ms) for button hovers and thumbnail selections, and standard (250ms) for the dropdown open/close and toast appearance. 25, 1), which is close to ease but slightly snappier on entry. 97) on active.

For the toast, they specify: enter from bottom with transform: translateY(100%) to translateY(0) over 250ms, auto-dismiss after 3 seconds with a fade-out over 200ms. The dropdown gets max-height animation replaced with transform: scaleY to avoid layout thrash. They add a motion budget rule: no more than two simultaneous animations. After generation, the product page feels responsive without being distracting.

The toast slides in cleanly, the button press feels tactile, and the dropdown opens without jank.

Example: Design system SKILL.md for a 15-person frontend team

A mid-size company with 15 frontend developers uses Claude Code across multiple repositories. Each repo has its own SKILL.md, and motion behavior is inconsistent: the marketing site has 400ms transitions everywhere, the app uses 200ms, and the docs site has no transitions at all. The design systems team needs to create a shared motion section that can be copied into every repo's SKILL.md. They have 90 minutes and need to handle both simple components and complex page transitions.

The design systems team audits three repos and catalogs 12 distinct motion patterns in use, ranging from button hovers to page route transitions. They consolidate these into four duration buckets: micro (100-150ms), standard (200-300ms), macro (300-500ms), and page (400-600ms). They define four easing custom properties and document when each applies. They build a comprehensive state specification table covering buttons, links, cards, inputs, toggles, and navigation items across default, hover, focus, active, and disabled states.

Each row specifies the exact properties that change and the exact duration. They write the transition property allowlist with detailed reasoning for each banned property. They add a reduced-motion section with fallback behaviors for each duration bucket. They include six inline code examples covering the most common components.

The total motion section is 550 words, under their 600-word target. md to three repos and regenerating a standard component set in each. Cross-repo consistency improves from roughly 30% motion behavior match to over 90%. The remaining 10% gaps are edge cases they add to a follow-up iteration.

Example: Mobile-first web app with gesture-like interactions

A B2C team is building a mobile-first task management app using Gemini CLI. The app relies on swipe-to-dismiss, pull-to-refresh, and bottom-sheet modals. Standard motion rules feel too desktop-centric. The team needs mobile-specific motion rules that account for touch interaction patterns and smaller screens.

The team starts with a standard motion section but adds a mobile-specific subsection. They define touch-optimized duration buckets: micro stays at 100-150ms, but standard drops to 180-250ms on viewports below 768px because mobile interactions feel laggier at 300ms. 72, 0, 1), which mimics iOS sheet behavior and feels natural on touch devices. For swipe-to-dismiss, they write a rule that the dismissal animation should match the gesture velocity, with a minimum of 150ms and maximum of 300ms, using --ease-exit`.

Pull-to-refresh gets a dedicated rule: the loading indicator should use a continuous rotation at constant speed (linear easing, one of the few valid uses), with the pull gesture itself using spring easing for the overscroll bounce. They add a rule that no mobile interactive element should have a hover state, only focus and active states, because hover is unreliable on touch. After regeneration, the bottom sheet slides up with natural spring physics, swipe dismiss feels responsive, and the pull-to-refresh bounce matches platform conventions. The absence of hover states on mobile eliminates the sticky-hover bug that plagued their earlier builds.

Best Practices

  • Define motion as CSS custom properties (e.g., --duration-micro: 150ms, --ease-enter: cubic-bezier(0.0, 0.0, 0.2, 1)) in your SKILL.md rather than raw values. Custom properties give the AI agent semantic names to reference, which reduces errors and makes the generated code more maintainable. Without them, the agent will hardcode different cubic-bezier values across components, creating inconsistency that is painful to audit.

  • Keep your transition property allowlist as a strict deny-by-default rule: only the listed properties may be transitioned. If you frame it as a suggestion ('prefer these properties'), the AI agent will treat it as optional and fall back to transition: all when uncertain. Frame it as a constraint ('only these properties are valid for transition') and the agent will comply more reliably.

  • Test motion rules on mobile viewports and low-powered devices, not just desktop. A 300ms animation that feels smooth on a MacBook Pro may stutter on a budget Android phone. Include a rule in your SKILL.md that mobile viewports (below 768px) should use the shorter end of each duration range. This nudges the agent toward faster, lighter animations on smaller screens.

  • Always pair motion rules with your anti-slop review criteria. Add specific motion checks to your anti-slop review rules: 'No component may use transition: all,' 'No interactive element may lack a hover state,' 'No modal may appear without an entrance transition.' This creates a feedback loop where the review rules catch motion violations the generation rules missed.

  • Version your motion rules section with a date stamp at the top (e.g., ## Motion Rules (v2, 2025-06-15)). When you update durations or easing curves, the date stamp lets you correlate agent output quality with specific rule versions. This is especially useful when debugging regressions after SKILL.md edits.

  • Write motion rules in order of frequency: put the most commonly needed rules (button hover, modal enter, tooltip fade) at the top of the section and edge cases (page transitions, skeleton loaders) at the bottom. AI agents weight earlier content in instruction files more heavily, so front-loading high-frequency rules improves compliance on the components that matter most.

  • Include a 'motion budget' constraint: no single page should have more than three simultaneous animations running at once. This prevents the AI agent from creating pages where everything bounces, slides, and fades simultaneously, which feels chaotic and degrades performance. State it as a hard rule, not a guideline.

Common Mistakes

Using transition: all as the default transition declaration

Correction

This is the most common AI-generated motion anti-pattern. It animates every CSS property, including layout-triggering properties like width and padding, causing janky reflows on every state change. Catch it by searching generated code for the string transition: all. Replace it with an explicit property list from your allowlist, e.g., transition: background-color 150ms var(--ease-enter), box-shadow 150ms var(--ease-enter). If your SKILL.md says 'avoid transition: all,' upgrade the language to 'never use transition: all; always list properties explicitly.'

Applying the same duration to all transitions regardless of context

Correction

AI agents default to uniform durations (typically 300ms or 200ms for everything) because most training data uses a single duration value. This makes micro-interactions feel sluggish and macro transitions feel abrupt. The diagnostic sign is that a color change on hover takes the same time as a modal entrance. Fix this by using your duration buckets explicitly in rules: 'hover color changes: 100-150ms; modal entrance: 300-400ms.' Name the buckets in the rule so the agent can match the context to the correct bucket.

Writing motion rules as vague preferences instead of enforceable constraints

Correction

Rules like 'use smooth easing' or 'animations should feel natural' are interpreted differently on every generation. The agent has no fixed definition of 'smooth' or 'natural,' so it falls back to its training distribution, which is exactly the default behavior you are trying to override. Replace every vague adjective with a specific value: 'use cubic-bezier(0.0, 0.0, 0.2, 1) for enter transitions' leaves zero room for interpretation. If your validation step (Step 8) shows inconsistent output, search your SKILL.md for adjectives and replace them with numbers.

Forgetting to specify reduced-motion behavior

Correction

Without explicit reduced-motion rules, the AI agent will generate animations that are inaccessible to users with vestibular disorders. This is both an accessibility violation and a legal risk. The diagnostic sign is the absence of any prefers-reduced-motion media query in generated CSS. Fix this by making the reduced-motion section mandatory in your SKILL.md, not optional. State it as a hard accessibility requirement with the specific override behavior: 'When prefers-reduced-motion: reduce is active, set all transition durations to 0ms and remove all keyframe animations except opacity fades.'

Animating entry without animating exit

Correction

AI agents frequently add entrance animations to modals, dropdowns, and toasts but omit the exit animation, causing the element to disappear abruptly. This asymmetry feels broken to users. Catch it by testing the dismiss action of every component that has an entrance animation. Fix it by pairing every entrance rule with a corresponding exit rule in your SKILL.md: 'Modals must enter with a fade-up over 300ms using --ease-enter AND exit with a fade-down over 200ms using --ease-exit.' The exit should be slightly faster than the entrance so dismissal feels responsive.

Overloading the SKILL.md with too many motion rules, causing the agent to ignore later rules

Correction

AI agents have finite context windows. If your motion section exceeds 800-1000 words, the agent may start dropping rules that appear later in the section. The symptom is that early rules (like duration buckets) are followed but later rules (like reduced-motion overrides) are ignored. Fix this by keeping the motion section under 600 words, using tables instead of prose for repetitive specifications, and placing the most critical rules (property allowlist, reduced-motion) in the first half of the section.

Other Skills in This Method

Enforcing Typography and Spacing Standards in AI-Generated UI

Teaches how to write and apply SKILL.md rules that govern font sizing, line height, letter spacing, whitespace, and visual density to eliminate generic-looking layouts.

Writing Anti-Slop Design Review Rules

How to author SKILL.md checklist rules that catch common AI-generated UI anti-patterns such as oversized padding, default border-radius, and bland color choices before code ships.

Configuring Layout and Visual Density Constraints for AI Agents

Teaches how to define grid, container, and density rules inside skill files so AI agents produce tighter, more intentional page compositions instead of loosely spaced defaults.

Auditing AI-Generated Frontends for Design Quality

A structured review workflow for evaluating AI-produced React and Next.js interfaces against Taste Skill criteria covering hierarchy, contrast, alignment, and component consistency.

Installing SKILL.md Files in AI Coding Agents

How to set up and configure Taste Skill instruction files in tools like Cursor, Claude Code, Codex, Gemini CLI, and v0 so your agent follows design-quality rules.

Authoring Portable SKILL.md Files for Design Systems

Teaches how to create reusable, framework-agnostic SKILL.md instruction files that encode your team's design-system tokens, component conventions, and aesthetic judgment for any AI agent.

Frequently Asked Questions

How do I choose between CSS transitions and CSS keyframe animations in my motion rules?

Use CSS transitions for state changes between two known states (hover on/off, visible/hidden, expanded/collapsed). Use CSS keyframe animations for multi-step sequences, looping animations, or entrance animations where the starting state is not already rendered in the DOM. In your SKILL.md, specify which components use which approach. Most interactive states (buttons, links, dropdowns) should use transitions. Modals, toasts, and skeleton loaders typically need keyframe animations because their initial state is 'not present.'

How long should it take to write a complete motion rules section for a SKILL.md file?

For a typical project, 45-90 minutes on the first pass. This includes auditing current output (15 min), writing duration buckets and easing mappings (15 min), specifying interactive states (15 min), writing the allowlist and reduced-motion rules (10 min), and adding inline code examples (10 min). Subsequent updates to an existing motion section usually take 15-20 minutes. The time investment pays off immediately because you stop manually fixing motion issues in every generated component.

Should I add motion rules before or after writing typography and spacing rules in my SKILL.md?

Write typography and spacing rules first. Motion operates on top of the visual resting state that typography and spacing define. If your spacing is wrong, your animations will move elements to incorrect positions. If your typography is unsettled, text transitions will feel off because the text itself looks wrong. The recommended order is: typography, spacing, layout density, then motion. See [enforcing typography and spacing standards](/skills/enforcing-typography-and-spacing-standards) for the foundational layer.

Why does my AI agent keep ignoring the easing curves I specified in my SKILL.md?

Three common causes. 2, 1)`). Second, the curves are too far down in the motion section and the agent's context window is deprioritizing them. Move easing rules to the top of the motion section. Third, you did not include a code example showing the curve in use. AI agents follow concrete examples more reliably than abstract rules. Add a 5-line CSS snippet showing the curve applied to a real component.

How do I handle motion rules for components that have both CSS transitions and JavaScript-driven animations?

Specify in your SKILL.md which components are CSS-only and which require JavaScript animation (e.g., drag-and-drop, gesture tracking, physics-based spring animations). For JS-animated components, define the same duration and easing constraints but reference them as JavaScript constants rather than CSS custom properties. Include a rule that JS animations must still respect `prefers-reduced-motion` by checking `window.matchMedia('(prefers-reduced-motion: reduce)')`. The key principle is that the constraint is the same regardless of implementation method.

Can I have different motion rules for different sections of my application?

Yes, but use a layered approach rather than separate rule sets. Define a base motion section that applies globally (duration buckets, easing curves, allowlist, reduced-motion). Then add context-specific overrides for sections that need different behavior, like a marketing landing page that uses slightly more dramatic animations than the core app. Keep overrides minimal, no more than 5-10 lines each. md files](/skills/authoring-portable-skill-files-for-design-systems).

How do I prevent the AI agent from adding gratuitous animations to elements that should be static?

Add an explicit 'no animation' list to your motion section. Specify components and elements that must never be animated: body text, navigation links in the header (hover color change is fine, but no bouncing or scaling), form labels, table data cells, breadcrumbs. Frame it as a constraint: 'The following elements must have no transition or animation properties: [list].' This is as important as specifying what should animate because AI agents, when given motion instruction, sometimes over-apply it to everything on the page.