@ryuxdsgn/design-intelligence 2.6.2 → 2.6.4

package/dist/cli/index.js

@@ -358,6 +358,7 @@ const CONTEXT_FIELDS = [
             ] },
     },
     { label: "Brand and design system", hint: "" },
+    { label: "Product docs", hint: "paths RYUX reads for product facts, for example docs/prd.md:" },
     { label: "Evidence sources", hint: `RYUX MCP (hosted server not live yet; local: ${MCP_LOCAL_ADD_CMD}), Figma files, reference URLs:` },
     {
         label: "Constraints", hint: "platforms, accessibility target (for example WCAG 2.2 AA), what must not change:",

package/dist/intelligence/content.js

@@ -47,13 +47,14 @@ 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", [
         {
             num: 1,
             title: "State the context first",
             level: "required",
-            do: "Before designing, write down the user, their task, the business goal, the design intent (what the user must understand, feel, and do), the information that matters, the primary action, the constraints, and what success looks like. Take what the prompt and DESIGN.md already give; ask only when a missing answer would change a major decision, at most three questions in one message (none when the context is complete), and write the rest as assumptions.",
+            do: "Before designing, write down the user, their task, the business goal, the design intent (what the user must understand, feel, and do), the information that matters, the primary action, the constraints, and what success looks like. Take what the prompt and DESIGN.md already give; ask only when a missing answer materially affects the user flow, what the product can do, or whether the content is correct, or when neither the prompt nor DESIGN.md sets the UI or motion direction, at most three questions in one message, most consequential first (none when the context is complete). Otherwise make the smallest reasonable assumption, write it down, and continue.",
             dont: "Start from a generic template with no stated user or task, or ask questions the prompt or DESIGN.md already answers.",
             why: "Without a task, design and review drift into taste.",
             basis: "ryux-critique playbook; NNGroup task-based evaluation",
@@ -64,10 +65,11 @@ export const RULES = [
             title: "Unknowns stay assumptions",
             level: "required",
             gate: "hard",
-            do: "List what you do not know as assumptions, and mark the matching UI with [REAL DATA] or a question. Product facts (feature and tool names, commands, integrations, supported platforms, page names) come only from the brief, the repo, or the product's own docs.",
-            dont: "Invent business rules, metrics, user data, permissions, pricing, requirements, or API behavior, or name a tool, command, integration, platform, or page the product does not have.",
-            why: "Invented facts turn into promises and bugs that someone has to unwind.",
-            basis: `${RUN}: an unconstrained agent invented a 30-day trial and user counts`,
+            do: "Sort what the brief does not say into three kinds. Design assumptions (low-risk visual or structural choices such as a merchant category icon or grouping by date): decide them from the context. Unconfirmed capabilities (an action or feature the category usually has, such as sharing a receipt): convention is not proof, so ask when it materially changes the flow or scope; otherwise you may propose it, listed as unconfirmed, never as a requirement. Facts, claims, and policies: take them only from the brief, the repo, or the product's own docs (feature and tool names, commands, integrations, platforms, pages, fees, timings, guarantees).",
+            dont: "Invent business rules, policies, guarantees, metrics, user data, permissions, pricing, requirements, or API behavior, or name a tool, command, integration, platform, or page the product does not have. Do not present an unconfirmed capability as a confirmed one.",
+            notWhen: "This rule is not a reason to drop content the brief implies or to leave a screen looking unfinished: sample content is RX-AS-03, design assumptions are yours to make.",
+            why: "Invented facts turn into promises and bugs that someone has to unwind; a screen trimmed to the brief's literal words reads unfinished and hides what still needs confirming.",
+            basis: `${RUN}: an unconstrained agent invented a 30-day trial and user counts; ryux visual benchmark 2.6 human rater, 2026-10-13: RYUX screens lost on a missing receipt action`,
             check: "review",
         },
         {
@@ -644,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",
@@ -1039,13 +1041,13 @@ export const RULES = [
         },
         {
             num: 3,
-            title: "Placeholders look like placeholders",
+            title: "Sample data is realistic and labeled; placeholders only for what is missing",
             level: "required",
             gate: "hard",
-            do: "Mark temporary content clearly: [REAL DATA], [LOGO], \"Contoh data\".",
-            dont: "Ship placeholder copy or data disguised as final.",
-            why: "Disguised placeholders ship by accident.",
-            basis: "ryux anti-slop principle",
+            do: "Fill mockups with realistic sample content consistent with the brief (names, merchants, amounts in the brief's currency, dates) and list it as sample data in the output. Keep a visible placeholder only for an asset that does not exist yet, such as [LOGO].",
+            dont: "Put [REAL DATA], XXX, or lorem text on the canvas where sample data would do, or ship sample data or placeholder copy as final. A sample-data label does not turn a fee, policy, or claim into a fact (RX-PR-02).",
+            why: "Bracketed values read as unfinished and hide the layout's real behavior; unlabeled sample data ships by accident.",
+            basis: "ryux anti-slop principle; ryux visual benchmark 2.5, 2026-10-09: [Brand] and XXX read as unfinished",
             check: "audit_copy C-01",
             formerly: ["RX-C-05"],
         },

package/dist/intelligence/guides.js

@@ -40,9 +40,9 @@ accessibility, and intentional decisions. Understand the context before deciding
 facts from assumptions; prefer evidence over aesthetic preference; do not invent requirements;
 explain meaningful decisions with their trade-off; validate before claiming.`;
 export const CORE_WORKFLOW = `1. **Understand the request**: who, what task, which product and market (RX-PR-01). Read the
-   RYUX project context in DESIGN.md first when it exists; do not guess what it leaves blank. Ask
-   only when the answer would change a major decision (at most three, usually none), and assume
-   the rest visibly. DESIGN.md answers are direction, not evidence of what users need.
+   RYUX project context in DESIGN.md, then the product docs (Product docs paths, else PRD.md,
+   docs/prd*, docs/product*, README), and name what you read. Ask and record direction as in
+   capabilities/design.md, step 1; assume the rest visibly. DESIGN.md is direction, not evidence.
 2. **Pick the entry point** and read its file.
 3. **Select knowledge**: read the modules the task table lists, and no others.
 4. **Gather evidence**: reference screens through the ryux MCP when connected; otherwise say so.
@@ -61,9 +61,22 @@ export const DESIGN_BODY = `# RYUX Design
 
 1. **Context.** Who, what task, which product and market, and the design intent
    (knowledge/product.md). Take it from the prompt, then DESIGN.md, then knowledge and evidence.
-   Ask only when a missing answer would change a major decision: those questions alone, at most
-   three, in one message, before designing. Complete context means no questions. Never ask what
-   the prompt or DESIGN.md already answers; write the rest down as assumptions (RX-PR-01).
+   Read the product docs first (the router, step 1). Ask only when a missing answer materially
+   affects the user flow, what the product can do, or whether the content is correct, those
+   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. **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
+   answer into the UI direction or Motion direction field of the RYUX project context in DESIGN.md:
+   between \`<!-- ryux-context:start -->\` and \`<!-- ryux-context:end -->\`, one line per field
+   (\`- **UI direction**: Calm, trustworthy\`). If DESIGN.md or the block does not exist, create it
+   with those two fields. Change only those field lines; leave every other line as it is. Your own
+   assumptions do not go into DESIGN.md.
 2. **Understand what exists.** When there is a screen, product, or design system already, read its
    analysis or run Analyze first (capabilities/analyze.md). Understand before you design.
 3. **Decide with evidence.** For consequential choices, compare two or three patterns, using
@@ -83,7 +96,8 @@ export const DESIGN_BODY = `# RYUX Design
    gate. Never finish with an asset still pending.
 8. **Fact check, then the gate.** Check every product fact on the canvas (tool and command names,
    integrations, platforms, pages, numbers) against the brief or the repo (RX-PR-02), then close
-   with the Delivery Gate, saying what was not designed, such as other widths or states.
+   with the Delivery Gate, saying what was not designed, such as other widths or states. If you
+   wrote DESIGN.md, say so in the final message: which file and which fields.
 
 Do not edit frames you were not asked to change. Do not hand off a design as "final" with
 placeholder or invented content.
@@ -120,7 +134,11 @@ Asset direction per asset: purpose, source, style, composition, context, consist
                avoid, provenance (observed, sourced, illustrative, generated, inferred)
 Responsive     what changes, stays, disappears, or stacks at each width
 
-Assumptions    everything guessed, visible
+Assumptions    kept apart, all visible:
+               design assumptions (low-risk choices made from context);
+               unconfirmed capabilities (actions or features on the canvas the brief did not
+               confirm; proposed, not requirements); sample data (realistic mockup content,
+               never a fact, RX-AS-03)
 Decisions      one Decision Receipt per major decision (below)
 \`\`\`
 
@@ -161,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
@@ -223,10 +243,13 @@ export const GUIDES = {
 5. **Primary action**: the one thing this screen exists for.
 6. **Constraints**: platform, data that exists, technical or legal limits.
 7. **Success**: how would you know the screen works?
-8. **Assumptions**: everything you had to guess. Keep them visible.
+8. **Assumptions**: everything you had to guess, kept visible and sorted into design assumptions,
+   unconfirmed capabilities, and sample data.
 
-Unknown facts stay assumptions. Do not invent business rules, metrics, user data, permissions,
-pricing, requirements, or API behavior; mark them [REAL DATA] or ask.
+Unknown facts stay assumptions. Do not invent business rules, policies, metrics, user data,
+permissions, pricing, requirements, or API behavior; ask when one materially affects the flow or
+correctness, otherwise leave it out. Mockup content is realistic sample data, labeled (RX-PR-02,
+RX-AS-03).
 
 Find evidence with the ryux MCP (\`search_screens\`, \`get_flow\`, \`get_local_pattern\`) and cite the
 \`screen_id\`, or call the decision a judgment call.
@@ -403,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/dist/render.js

@@ -134,7 +134,8 @@ ${GUIDES[s.id]}${extra}
 ${s.evidence} Without the ryux MCP, say the evidence comes from the design and standards alone.
 
 > Hard Gates always apply, whichever skills are loaded: no invented numbers, people, urgency, business
-> rules, or terms; no placeholder shipped as final; no missing critical states. See \`ryux-core\`.
+> rules, or terms; no placeholder shipped as final; no missing critical states. Labeled sample data is
+> not an invented number; an unconfirmed capability is never presented as confirmed. See \`ryux-core\`.
 
 ## Rules
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ryuxdsgn/design-intelligence",
-  "version": "2.6.2",
+  "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": {