@ryuxdsgn/design-intelligence 2.6.3 → 2.6.4

package/dist/intelligence/content.js

@@ -47,6 +47,7 @@ function skill(id, rules) {
 const RUN = "ryux run 2026-10-02";
 // Rules that cover a pattern another MIT ruleset also names; the text and numbering are RYUX's own.
 const AS = "anti-slop (MIT)";
+const EK = "emilkowalski/skills (MIT)";
 export const RULES = [
     ...skill("product", [
         {
@@ -645,10 +646,10 @@ export const RULES = [
             title: "Motion earns its level",
             level: "contextual",
             when: "the design adds motion or transitions",
-            do: "Classify each motion: L1 state feedback, L2 component transition, L3 page transition, L4 storytelling, L5 decorative. The higher the level, the stronger the reason it needs. Take timing and easing from one motion personality, define them once as motion tokens, animate transform and opacity rather than layout properties, and honor reduced motion (RX-A11Y-08).",
-            dont: "Animate everything, use one generic duration and easing (transition: all 0.3s) everywhere, or let decorative motion delay content or input.",
+            do: "Classify each motion: L1 state feedback, L2 component transition, L3 page transition, L4 storytelling, L5 decorative. The higher the level, the stronger the reason it needs. Then weigh how often people see it: a surface opened many times a day (command palette, shortcut, core navigation, list selection) appears and closes without movement, at most a fade too short to notice; standard transitions belong to occasional surfaces (modal, drawer, toast), and expression to rare or first-time moments. Take timing and easing from one motion personality, define them once as motion tokens, animate transform and opacity rather than layout properties, and honor reduced motion (RX-A11Y-08).",
+            dont: "Animate everything, give a surface people open many times a day an entrance they must sit through, use one generic duration and easing (transition: all 0.3s) everywhere, or let decorative motion delay content or input.",
             why: "Motion directs attention; unearned motion steals it from the task and can make some people unwell.",
-            basis: "NNGroup animation and usability guidance; WCAG 2.3.3 animation from interactions",
+            basis: `NNGroup animation and usability guidance; WCAG 2.3.3 animation from interactions; frequency check: pattern also in ${EK} find-animation-opportunities, written for RYUX`,
             notWhen: "L1 feedback on standard controls that follows the platform defaults",
             tradeoff: "fewer flourishes on marketing pages",
             check: "review; reduced-motion test",

package/dist/intelligence/guides.js

@@ -66,7 +66,9 @@ export const DESIGN_BODY = `# RYUX Design
    questions alone, most consequential first, at most three, in one message, before designing.
    **Direction is the user's call:** when neither the prompt nor DESIGN.md sets the UI direction
    (character, or brand colour and type) or the motion direction, ask for it in that message (it
-   counts toward the three) instead of choosing it yourself. Complete context means no questions. Never ask what the prompt, DESIGN.md, or the
+   counts toward the three) instead of choosing it yourself. **No DESIGN.md and no product docs is the
+   case where these questions matter most, never a reason to skip them:** ask, then wait for the
+   answer before designing. Complete context means no questions. Never ask what the prompt, DESIGN.md, or the
    product docs already answer. For the rest, make the smallest reasonable assumption, write it
    down, and continue (RX-PR-01, RX-PR-02).
    **Record direction answers.** When the user answers a UI or motion direction question, write the
@@ -177,7 +179,9 @@ export const BUILD_BODY = `# RYUX Build
    approved mockup; it is the spec. If there is none, run Design first (capabilities/design.md)
    instead of inventing one in code.
 3. **Read the modules the task needs** from the task table: for example accessibility, responsive,
-   and edge-cases for any UI, and forms and content for a form.
+   and edge-cases for any UI, and forms and content for a form. When the build adds motion or
+   transitions, read knowledge/ui.md (RX-UI-11) before writing any: how often the surface is seen
+   decides how much it moves.
 4. **Implement faithfully.** Use semantic elements, existing components, and real data paths.
    Build must not invent business rules, prices, or limits; API behavior or response shapes; or
    data presented as real (RX-FE-02, RX-PR-02). It must not silently change a design decision: a
@@ -422,6 +426,9 @@ If not, the surface has no point of view yet. Stay honest while being bold: a st
 needs invented numbers, people, or logos.
 
 **3. Motion.** Start from purpose: what the motion communicates; with no purpose, no motion.
+Then ask how often someone will see it. The more often, the less of it they should notice: what
+people open many times a day (a command palette, a shortcut, core navigation) appears at once, and
+expression is kept for occasional or first-time moments. A purpose does not outweigh frequency.
 Every motion follows one lifecycle: before, trigger, transition, new state, feedback.
 The states themselves (waiting, result, recovery) are defined in ryux-interaction (RX-IX-01,
 RX-IX-02); motion only makes them visible, and it never compensates for weak UX. Decide the trigger,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ryuxdsgn/design-intelligence",
-  "version": "2.6.3",
+  "version": "2.6.4",
   "description": "RYUX: design intelligence for AI agents and designers. One skill, five entry points: Analyze, Design, Build, Critique, and QA, for Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Cline, Copilot, and more.",
   "type": "module",
   "bin": {