| name | oil-ux |
| description | 仅当用户明确要求使用 oil-ux 时触发，例如写出 $oil-ux、说“用 oil-ux”或“使用 oil-ux”，或通过技能选择器选择本技能。仅提到 oil-ux 名称，或请求涉及 UX/UI、页面、组件、CSS、表单、交互、布局、视觉评审或重构，均不得自动触发。触发后，按本规范审查、设计或重构产品界面与交互。 |
Oil UX
先识别任务和作用域，再删除无效内容，建立信息与动作层级，最后修改数据流、布局和共享组件。
术语速查
本文件和参考规则中的核心词汇，按这里的定义理解：
- 资源身份：让用户认出"这是哪个对象"的最小信息组合——图片 + 名称 + 一个区分字段。例：成员列表显示"头像 + 姓名 + 部门"，而不是"uuid + 类型标签"。
- 伪操作：看似可用、实际不产生真实结果的控件。例：点"保存"只改了本地 state、刷新即丢失；删除按钮永久 disabled 占位。
- 单个组件的视觉补丁：在页面使用共享组件的位置，只给这一个组件补样式。例：
<Dialog className="h-[640px]">、!important 覆盖、页面专属选择器改组件内部。正确做法是修共享组件本身，或新增按用途命名的组件变体。
- 按用途命名的组件变体（variant）：用“为什么不同”命名。例：
variant="destructive"、size="compact" 合格；variant="blue"、variant="userListPage" 不合格。
- 主导动作：当前决策上下文中完成主要任务的那一个操作。同一上下文最多一个高强调按钮。
- 提交边界：一次修改何时真正生效——即时生效、自动保存、显式统一提交，或仅临时预览。
- 忙碌范围：请求进行中需要防止重复操作的最小区域。单项请求只锁定该项，不用全页遮罩。
- 已提交查询快照：由同一次响应共同确定的查询条件、列表、结果总数和分页信息。新查询完成前，旧快照仍属于旧条件。
- 同构任务：对一批同类对象重复填写相同字段的任务，如批量排期、批量改价。
- 可编辑工作表：为批量配置同构任务而让多行持续处于编辑态的表格。与之相对的是资源目录：默认展示态，编辑必须明确触发。
核心原则
- 可见内容必须帮助用户识别对象、比较差异、判断状态、理解必要规则或风险、执行动作或理解结果。
- 当对象、操作顺序、控件和反馈已经通过界面结构清楚表达时，不再用说明文案重复解释流程；只为非共识规则、系统限制、误操作风险或不可逆后果补充必要说明。
- 不复述用户刚完成且界面已经清楚表达的局部状态；只有状态或数量会改变下一步动作、作用范围或结果判断时才显示。
- 一个用户意图只执行一次；界面动作必须对应真实的数据变化、导航或结果。
- 资源浏览默认使用展示态；批量配置同构任务时可以直接使用可编辑工作表。
- 字段由其业务对象的所有者负责编辑；消费页面只展示、引用或选择。
- 实现信息只在直接影响当前判断或操作时展示，且不能取代用户能够识别的业务身份。
- 常见任务使用用户已经理解的结构、术语和操作方式；同一对象和动作保持相同含义。
- 图标只在确实能加快识别时使用，并表达明确的对象、动作、状态或结果；不为填空、统一形式或装饰页面而滥用。
- AI 功能按真实动作、对象或结果选择图标，不把星星、闪光、机器人、脑形或魔法棒作为默认的 AI 装饰。
- 表单只收集完成任务必需且无法可靠获得的数据。
- 谨慎使用容器左侧或顶部的彩色强调边、色带和装饰性轨道；只有它持续表达可复用的状态、类别或选择含义时才保留，不把它作为普通卡片和列表项的默认装饰。
- 默认让内容、Flex/Grid 和父容器边界决定尺寸；只有固定尺寸保护明确行为时才允许，并由共享组件或统一设计变量负责。
- 先修数据范围、父布局和共享组件；使用共享组件的页面不负责修补组件内部视觉。
- 同一含义只保留一个组件、函数和样式来源：页面负责组合，组件负责自身视觉与状态，独立函数负责转换和校验；替换实现时同步删除旧代码与旧样式。
- 项目既有模式只是起点，不是正确性的证明；只有职责清晰、行为真实、数据完整且符合组件与样式所有权时才复用。既有实现本身错误时，停止复制，修复或替换真正出错的共享实现，并处理所有受影响的使用位置。
决策顺序
改动前依次回答。
任务与对象：
- 用户当前要完成什么任务，什么结果表示完成？
- 页面管理哪个核心对象，字段分别归谁所有？
- 当前是浏览、比较、选择还是编辑，是否沿用用户熟悉的结构和术语？
数据与范围：
- 数据来自完整集合、当前可见集合还是搜索结果？
- 操作、忙碌状态和提交边界分别影响什么范围；远程查询条件与当前列表是否已经属于同一次已提交结果？
- 用户靠哪些信息区分相邻对象？
- 能否删除文字、步骤、确认、重复输入或系统已经知道的字段？
- 哪些信息属于集合，哪些只属于详情？
结构与状态：
- 当前决策上下文的主导动作是什么？
- 首屏、滚动容器和弹层边界分别由谁负责？
- loading、empty、filtered-empty、queued、processing、error、ready 如何互斥？
落点：
- 是否已有可复用的组件、函数、统一设计变量或样式，最终应修改哪个数据源、父布局或共享实现？
无法明确回答时，先停止添加界面元素：向用户提出最关键的 1–2 个问题；无法提问时按最小作用域实施，并在输出中声明所做的假设。
执行流程
1. 还原事实
- 搜索项目已有的组件、函数、统一设计变量和样式，确认相同含义是否已经存在正确实现。
- 找出所有使用共享组件的页面和组件，以及相同数据的其他入口。
- 评审请求只给证据与建议；用户要求修改时才实施。
2. 建立作用域
- 明确核心对象、字段所有者、数据集合、操作范围、忙碌范围和提交边界。
- 区分页面结构问题、组件默认行为、页面使用方式错误和数据流错误。
3. 先删除
- 删除不影响判断的内容、重复状态、重复入口、重复确认和只针对单个组件的视觉补丁。
- 删除没有真实状态变化或不能真正保存数据的伪操作。
- 删除已经被新实现替代的旧组件、旧函数、旧样式类、旧样式和失效引用。
4. 选择结构
- 先检查项目中同类任务页面和共享表面组件的既定用法；只有既有模式符合本规范时才沿用，否则按真实任务重新选择结构。
- 根据浏览、比较、选择、批量配置或深度编辑任务，读取对应规则后选择列表、表格、工作表、选择器、弹窗或完整工作区。
- 让列表负责识别和比较，让详情负责完整内容，让编辑器负责修改。
5. 修复真正出错的位置
- 优先修复数据范围、操作作用域、父布局、共享组件默认行为和含义稳定的组件变体。
- 重复出现的资源身份、菜单、弹层、加载、弹窗和操作栏使用共享组件。
- 只有职责、输入输出和行为稳定重复时才抽象；不要因为局部结构相似就复制组件，也不要用大量页面开关制造万能组件。
- 既有共享组件、函数、样式或数据流本身错误时，在授权范围内直接修复或替换真正出错的共享实现，并处理所有受影响的使用位置；不要为了兼容历史继续新增错误实现。
- 无法在当前范围内全部改完时，停止扩大旧模式，明确报告还剩哪些旧使用位置以及这次改到哪里，不得声称已经统一。
- 修复可重复检测的问题时，同步补齐或优化项目内的 lint、测试或检查规则（见 automation-contract.md）；小改动不为此前置搭建自动化。
- 不修改无关区域。
6. 验证
独立自检
仅当 UX Review 涉及多个页面、所有使用共享组件的位置、多种视口或状态，或大范围规则调整时，才派发无历史上下文的独立自检。单页面、单组件、单截图和局部差异由主 Agent 直接检查。
独立自检只接收检查对象、范围和 oil-ux，不接收对话历史、既有结论、问题猜测、预期答案或修复方案。
参考文件
只读取当前任务需要的文件：
输出要求
先给结论，再给证据。只输出：
- 具体问题；
- 应删除的内容；
- 正确的信息、动作和空间结构；
- 应修改的共享组件或数据流；
- 已验证和未验证项。
禁止使用"提升体验""更现代""更直观"等不能指导实现的描述。
除非用户明确要求，或问题直接阻断可见的主要流程，否则不主动输出键盘操作或无障碍检查清单。
