RYUX RX-2.0（规则 v1.3.1）采用 MIT 许可，定位为面向 AI 与设计师的设计智能层。其目标是通过设计推理帮助理解、构建、评估与修复界面，并明确声明自身不是 UI 生成器、不是反套路框架，也不是设计系统。
用途与能力 RYUX 提供四种能力入口：Analyze 用于理解已存在的界面；Build 用于创建或修改 UI、文案或前端代码，需先依据证据做产品决策，再使用工作流与任务表；Critique 用于评估设计、页面或流程；QA 用于验证刚构建的内容。技能角色分为：core 作为操作系统；知识技能（产品、UX、交互、表单、边界情况、内容、UI、设计系统、无障碍、响应式、前端）提供推理方式；能力技能（分析、评审）是工作流；门禁技能（视觉 QA、反套路）负责验证与过滤。所有能力最终都落到 Anti-Slop 质量门禁，包括硬性门禁与交付门禁。
主要原则与工作流 原则强调不追求视觉新奇，而优化清晰度、可用性、一致性、产品契合度、无障碍与有意决策；先理解上下文再决策；区分观察事实与假设；偏好证据而非审美偏好；不虚构需求；对重要决策说明权衡；在声称之前先验证。工作流为：请求 → 理解上下文 → 理解产品问题 → 定义 UX 结构 → 定义交互 → 定义 UI → 应用设计系统 → 实现 → 检查（渲染）→ 评审 → 精炼 → 交付门禁 → 完成。可跳过不适用步骤，但不得从生成直接跳到完成。
等级与硬性门禁 规则分为 Required（需书面理由才可例外）、Preferred（默认，打破需简短书面理由）、Contextual（仅在特定情境适用）、Hard Gate（无例外，完成前必须修复）、Quality Lock（跨产品一致性）。硬性门禁始终适用，即使未加载 ryux-anti-slop，包括：不虚构数据或指标、不虚构推荐语或人物、不虚构业务规则或产品需求、不将占位文案作为最终内容交付、不制造虚假紧迫感或稀缺性、不缺失关键状态、不破坏响应式行为、不出现无障碍失败、不模糊主要操作、不交付行为未定义的交互、不创建重复组件、不添加不必要的复杂性。
构建任务与技能加载表 根据任务类型加载不同技能组合，例如 UI 实现需加载 ryux-product、ryux-ux、ryux-ui、ryux-design-system、ryux-frontend、ryux-visual-qa、ryux-anti-slop；表单实现需加载产品、UX、表单、交互、无障碍、边界情况、内容等；移动 UI、结账或支付、数据密集视图、前端逻辑或工具、仅文案、视觉精炼、评审等各有对应组合。评审或批评时使用 ryux-critique（Design Read + heuristic_eval）加 ryux-visual-qa。
交付门禁 结束 UI、UX、文案或前端工作时须输出报告，涵盖 PRODUCT、UX、UI、DESIGN SYSTEM、ACCESSIBILITY、RESPONSIVE、EDGE CASES、CODE QUALITY、VISUAL QA、ANTI-SLOP 十个领域，每项为 PASS、FAIL 或 N/A 并附一行理由；FINAL 仅在无 FAIL 时为 PASS。若某技能中的 Required 规则未获书面例外而失败，该领域 FAIL；硬性门禁失败不可例外，必须修复。有渲染工具时 VISUAL QA 不能在没有渲染的情况下 PASS，并需说明所用工具。
诚实声明与设计决策记录 报告需说明检查了什么、如何检查、哪些不可用，不得在无证据时声称“像素级完美”“完全无障碍”“生产就绪”“资深水平”或“UX 优化”。对于重要选择与偏差，需写设计决策记录，包括决策、比较选项、证据、权衡与选择；证据分为 Strong（2 个以上可比较 screen_id）、Thin（一个或另一上下文）、None（无 screen_id，属判断）；若重要选择证据为 None，应展示选项或询问。参考屏幕与结构化评审来自 ryux MCP（search_screens、heuristic_eval、delivery_gate），连接命令为：claude mcp add --transport http ryux https://mcp.ryux.design/mcp。
适用场景与限制 适用于需要设计推理辅助的界面分析、构建、评审与质量验证场景。限制包括：不是 UI 生成器或设计系统；不提供自动生成界面的能力；使用时需遵循技能加载表与门禁流程；部分能力依赖 ryux MCP 提供的参考屏幕与结构化评审。