@ryuxdsgn/design-intelligence 2.10.0 → 2.11.0

package/dist/intelligence/content.js

@@ -196,6 +196,18 @@ export const RULES = [
             check: "heuristic_eval H-06",
             formerly: ["RX-H-06"],
         },
+        {
+            num: 10,
+            title: "Change what is broken, keep what works",
+            notWhen: "a new product or screen with nothing to keep, or a brief that asks to replace the whole design",
+            tradeoff: "a redesign can look less new; the gain is in fewer regressions and less relearning",
+            level: "required",
+            do: "Before changing an existing screen or flow, list what works today (from Analyze, the user, or analytics) and keep it. Every significant change names the problem it fixes and its evidence (a Critique finding, a user report, a metric); a pattern with no named problem stays as it is. Report what was kept as well as what changed.",
+            dont: "Replace a working layout, component, or interaction for novelty; restyle parts the brief did not ask to change; or treat \"more modern\" as a problem by itself.",
+            why: "A redesign that throws away what people already know costs them relearning and can make the product worse while looking newer.",
+            basis: "ryux design principle (owner, 2026-10-19); Jakob's law (people expect a product to work like the ones they already know); ryux run: judge and motion benchmarks 2026-10-18; written for RYUX",
+            check: "the change list, each with its problem and evidence; the kept list; review",
+        },
     ]),
     ...skill("interaction", [
         {
@@ -703,11 +715,11 @@ export const RULES = [
             title: "A point of view on expressive surfaces",
             level: "contextual",
             when: "the surface is expressive: a hero, landing page, onboarding, empty state, or brand moment, or the brief asks for a new look or more personality",
-            do: "Before designing, make three directions, each with a name, a concept taken from the product's own idea (for a tool about evidence: receipts, citations, marks of proof), and a signature element (type, composition, imagery, or motion). Render them as frames of the main state with the same content, different on at least two structural axes (information order, layout model, interaction model, type class, colour temperature), rate each against criteria taken from the brief, recommend one (RX-PR-09), and let the user choose; then make the rest of the design serve the chosen signature and put its concept in the Visual Brief.",
-            dont: "Show three directions that differ only in colour or copy, choose for the user without showing them, or let the signature be the category's default (for developer tools a terminal or agent-session panel; for SaaS a dashboard screenshot; copy on the left and product on the right), or relabel that default as a concept. A product screen can support the signature, not be it.",
+            do: "Before designing, make three directions, each with a name, a concept taken from the product's own idea (for a tool about evidence: receipts, citations, marks of proof), and a signature element (type, composition, imagery, or motion). Render them as frames of the main state with the same content, different on at least two structural axes (information order, layout model, interaction model, type class, colour temperature), rate each against criteria taken from the brief, recommend one (RX-PR-09), and let the user choose; then make the rest of the design serve the chosen signature and put its concept in the Visual Brief. When the brief names reference products, read each one before it shapes the direction: the principle you borrow, what stays theirs (colours, mascot, signature features), and where you use it.",
+            dont: "Show three directions that differ only in colour or copy, choose for the user without showing them, or let the signature be the category's default (for developer tools a terminal or agent-session panel; for SaaS a dashboard screenshot; copy on the left and product on the right), or relabel that default as a concept. A product screen can support the signature, not be it. Turn a named reference into adjectives (\"calm, white, soft\") or copy what belongs to its brand.",
             why: "Users remember a product by its idea; a correct but generic surface is forgotten and could belong to any competitor.",
             basis: "brand and art direction practice; RX-UI-05 layout from content; rendered variants on named axes, compared side by side, chosen by the user: pattern also in emilkowalski/skills (MIT) prototype; written for RYUX",
-            notWhen: "task UI such as forms, tables, settings, and checkout, where restraint and convention win",
+            notWhen: "task UI such as forms, tables, settings, and checkout, where restraint and convention win: skip the three directions and keep structure and interaction conventional. A new product's brand layer may still carry one signature from the product's own domain (a mark, the type voice, or one brand moment in the flow), never a layout change and never decoration without a job (RX-AS-05)",
             tradeoff: "a strong idea takes a decision someone may disagree with; keep it honest and on brand",
             check: "the swap test (RX-AS-09); review",
         },
@@ -1184,7 +1196,7 @@ export const RULES = [
             dont: "Treat a tidy, generic layout as done because it passes every other gate; generic restraint is slop too.",
             why: "Removing slop is the floor, not the ceiling; interchangeable design makes the product forgettable.",
             basis: "ryux delivery principle; Critique Design Read: specificity",
-            notWhen: "task UI, where familiarity is the point",
+            notWhen: "task UI, where familiarity is the point: the structure stays familiar; on a new product, ask the swap question of the brand layer only (RX-UI-12)",
             tradeoff: "takes a design decision, not only removals",
             check: "swap test; review",
         },

package/dist/intelligence/guides.js

@@ -67,7 +67,8 @@ export const DESIGN_BODY = `# RYUX Design
    questions alone, most consequential first, at most three, in one message, before designing.
    A product rule that changes which states or actions the screen has (refunds, fees, what happens
    on failure) is a major decision. When the prompt and DESIGN.md disagree, the prompt wins for
-   this task; say so.
+   this task; say so. A DESIGN.md written for a different product (another name, domain, or
+   audience than this brief) sets no direction for this task: say so, and treat direction as unset.
    **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
@@ -84,7 +85,9 @@ export const DESIGN_BODY = `# RYUX Design
 2. **Understand what exists.** When there is a screen, product, or design system already, read its
    analysis or run Analyze first (capabilities/analyze.md). Existing screens, components, and any
    screenshot or reference provided are your examples: read them before choosing patterns, take
-   their principles, and never copy their facts. Understand before you design.
+   their principles, and never copy their facts. Understand before you design. When the task
+   redesigns or improves what exists, list what works and keep it; change only what has a named
+   problem (RX-UX-10).
 3. **Read the modules the task needs** from the task table before deciding anything, for example ux,
    interaction, forms, and content for a form, or ui and responsive for a layout; for any surface
    with a visual direction, ui and anti-slop as well. The rules shape the first idea, not only the
@@ -95,7 +98,8 @@ export const DESIGN_BODY = `# RYUX Design
    task, the one thing that must be seen first, and two or three UX approaches (structure and
    interaction model) before any visual work, and choose by the task; a small change skips this.
 5. **Direction.** Write the Design Direction below. On task UI, follow conventions and the design
-   system. On an expressive surface (hero, landing, onboarding, empty state, brand moment), or when
+   system; a new product's brand layer may carry one signature from its own domain, never a layout
+   change (RX-UI-12, Not when). On an expressive surface (hero, landing, onboarding, empty state, brand moment), or when
    the brief asks for a new look or more personality, explore on the canvas before choosing (RX-UI-12):
    - Render three directions as frames side by side: the main state only, the same content and
      sample data in each, each labelled with a name and a one-line concept.

package/package.json

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