Files
workbuddy_skills/oil-ui-pro/SKILL.md
T
admin 4ec25125d1 技能库本目录改建为 git 工作区(用户令「就在这个下面建立 git 推送就行」)
一、做法
把 E:/ProgramData/.workbuddy/skills 本身初始化为仓库(⛔ 不再用外部暂存目录),
远端=[email protected]:admin/workbuddy_skills.git;取回远端历史后只补差异。

二、仓库级配置(含一处**有意偏离**旧仓约定)
· core.autocrlf = **true**(旧仓是 false)。理由:本目录是 **Windows 原生工作区**(文件是 LF/CRLF 混合),
  而仓库里存的是 LF ⇒ 用 false 时 `git status` 报 **196 处"修改"**,实测**全是行尾**;
  改成 true 后降到 **16 处**,剩下的才是真差异。⛔ 否则一次提交会把几百个文件的行尾改掉。
  身份:maogeigei <[email protected]>。

三、本次提交
· `.gitignore` 扩充(按实测盘点补):logs/ · tmp/ · .venv/ · *.egg-info/ · uv.lock · node_modules/ ·
  .workbuddy/ · 四个宿主迁移标记 JSON(宿主每次启动可能重写,⛔ 不是内容)。
· `oil-ui-pro/SKILL.md`:把描述里的「不用于 A/B/C」改成「正向用途 + 一句邻接边界」
  (与 2026-10-07 `rules.md §9`「只写正向范围」同一条口径)。

⛔ 本轮**未纳管**(保持未跟踪,见下一条待拍板):AI HOT · draw-ui · dsh-diagnose · dsh-knowledge ·
  dsh-local-env · dsh-opensource-release · dsh-workflow · oil-motion · skills-security-check(共 9 个目录)。
2026-10-07 20:46:04 +08:00

12 KiB
Raw Blame History

name, description, allowed-tools, metadata
name description allowed-tools metadata
oil-ui-pro 设计、改进和评审网站、App、后台与组件的 UI/UX,完成设计方向探索、多风格同屏比较、视觉层级、任务流程、状态反馈、响应式布局和基于实际画面的迭代;按请求交付对比页、设计说明、设计稿或可运行界面。当用户需要新界面设计、比较不同设计风格、已有界面体验优化、视觉精修、截图还原或 UI/UX 评审时使用。只负责设计与体验判断(界面结构与观感、交互流程、状态反馈);组件归属、数据流、状态正确性与测试等代码实现质量,以及纯业务逻辑、接口与构建部署,走对应的工程技能。
Bash(sh *check_update.sh*)
Bash(python3 *check_update.py*)
Bash(python *check_update.py*)
Bash(py -3 *check_update.py*)
version compatibility
0.15.4 核心为宿主中立的文本流程,不依赖其他 Skill 或指定模型。可选风格对比页生成器需要 Python 3.10+ 标准库,产物仅需现代浏览器;本机地址候选需要对应的本地开发服务器在运行。实际视觉验收需要看图能力;交互验收需要可操作环境;独立评审需要隔离上下文且能看图的执行者。

oil-ui-pro

以明确的设计北极星组织界面,让构图、字体、色彩、素材和交互相互呼应,形成有辨识度的表达。克制是保留最有力量的选择、删除无贡献的元素,不是把所有风格磨成中庸。视觉表现与任务完成分别验收。

风格从这个页面的品类、首屏的主角和这个品牌里推出来,不从模型的默认模板里长出来。动手前先回答三件事:它是什么品类;用户来首屏看什么、做什么;同类最好的产品在首屏和控件上是怎么做的。方向只在这之上偏离,偏离要说得出来自这个产品的理由。

方法和评审协议均在本目录内,直接使用宿主提供的文件、浏览、看图、生成与隔离执行能力;不要求加载其他 Skill。截图、录屏、状态并排和遮字图用本目录的截图工具,写可操作小样的方式也在同一处,见 工具;不为取证另外加载浏览器类 Skill。前端实现规范以项目自己的约定为准,不另读前端类 Skill。相对链接以本文件所在目录解析。

开始前

版本检查:!sh "${CLAUDE_SKILL_DIR}/scripts/check_update.sh" 2>/dev/null || true

支持加载时运行命令的宿主会自动做这次检查,把结果填在上面;上面仍是一条命令时,运行本目录的 scripts/check_update.sh。它会先找 python3,再找 python,确认是 Python 3 后运行检查。没有 POSIX shell 的宿主,依次尝试 python3、python、py -3,确认是 Python 3 后运行本目录的 scripts/check_update.py。

检查由使用本 Skill 触发,最多每 10 分钟联网一次,网络失败后稍后重试,有新版本就尝试自动更新。结果为空就直接开始;说已自动更新时,重新读取本文件再开始;是一行更新提示时,照常完成任务,在最终回复末尾用当前对话的语言转述这行提示,命令、版本号和路径保持原样。

缺少 Python 3 时检查不会运行:照常完成任务,在最终回复里提醒一次“自动更新需要 Python 3”。结果是 OIL_UPDATE_CHECK_SKIPPED: missing_python 时说明已经提醒过,不再提醒,也不转述这个标记。手动运行检查的宿主,同一次对话里只提醒一次。

选择范围

  • 从请求、现有页面和参考资料明确用户、主要任务、真实内容、目标设备与交付形式。检查相关位置即可,不先通读整个项目。
  • 用户已确定的品牌、参考、页面结构和交互约束优先。分清借鉴风格、重新设计与精准还原,不能自行切换目标。
  • 仅在缺失信息会改变核心方向且无法合理推断时集中提问;可逆的细节自行决定并简述假设。
  • 设计说明、设计稿、原型和可运行产品是不同交付物。只要求评审时保持只读;只要求设计时不默认改业务代码。
当前范围 路径
单个元素、一处间距、文案或颜色这类小改动 直接改,在目标视口看改动处和相邻元素,交付时一两句话说明;不盘点现状、不开方向、不启动评审
新界面或明确要求重新探索 按步骤 1–5 执行;只交付设计说明时止于相应方案,并说明未渲染
已有方向的深化或局部优化 保留方向,从步骤 2 进入,只检查受影响的区域与状态
单个组件,要打磨到极致或做出辨识度 读 组件。组件在存量项目里时,样式按 存量项目 的“从源头修改”落到现有变量和组件上
存量项目里优化 UI、改流程或加新功能 读 存量项目,先分清是哪一种。改流程和加新功能不走步骤 1 的视觉方向探索,但本文开头的三问照答
截图还原 按 布局与视口 的“精准还原”,以参考图为视觉基线,确定参考视口与布局约束后进入步骤 2,不发散新风格
UI/UX 评审 按问题读取对应参考,只做步骤 4 的诊断,交付证据与建议

1. 探索并收敛方向

方向未确定时按 设计方向 走:认品类、拆标杆、定调性、起方向,写文案之前先定首屏骨架;多个方向时填方向卡、做差异检验。小样只做首屏和最能体现方向的一两个区块,方案数量按任务定。需要并排比较时,用 风格对比页 的模板和生成器。

方向由用户的品味来定:给出对比页和推荐理由,请用户选定,再说出具体喜欢和不喜欢哪里,按反馈收紧后再深化。用户让你自己决定或无法交互时,仍先出对比页留档,再选定并写明理由。

留一份简短的设计说明:用户任务、主动作、选定方向、关键状态、设备约束和验收重点。已有说明直接更新。

2. 建立视觉与交互结构

根据当前决策按需读取,不预先加载全部参考:

要解决的问题 参考
视觉层级、字体、色彩、空间、图标、风格统一或减法精修 视觉语言
用户流程、文案、动作、表单、选择、状态与失败恢复 交互与状态
页面、分栏、弹窗、浮层、滚动、响应式或截图还原 布局与视口
素材选择、视频与 3D 素材
生成配图:让图承担意思、写提示词、和页面接成一体 配图
三处基本动效与呼应、动效手感、界面过渡、首屏动画与滚动叙事、时长与检查 动效
点缀与特效:流动渐变、流光、点阵、颗粒、SVG 线条与排字 点缀与特效

新产品要交代主要内容的层级和关键操作链,不只做漂亮的默认状态。新界面和改动了操作流程时,按 动效 做出三处基本动效;小改动不加。

构图阶段先按 素材 判断图像能否承担主信息或情绪重心。需要关键素材时先选定或制作它,再围绕它安排文字和操作,不等布局填满后再补图。

既有项目先复用有效的设计变量、组件和交互习惯,修问题从源头修,不为一次调整另造设计系统,也不把无关代码重构混入视觉工作。具体做法见 存量项目。

3. 制作并取得实际证据

  • 先完成代表性页面或关键操作链,检查后再延展到其他页面。
  • 示例内容按真实产品的样子写。模拟数据、生成图片、未接入的动作写在交付说明里,不写进界面:画面上不出现“示例”“示意图”“按钮未接入”“仅保存在本机”这类制作说明。不伪造业务成功、客户评价或产品指标。
  • 在目标视口运行并查看,用 工具 里的截图工具取证:涉及的状态、200% 局部、动效的录屏或开始、中间、结束三帧。只有静态截图,证明不了动效。
  • 在实际阅读尺寸检查中文多行标题、正文和窄屏换行。文字重叠、被裁切或靠大量小字才装得下时,回到内容和布局修,不靠缩放掩盖。长页要检查整体节奏,不能只看首屏。截图保存成功不等于已经看过。

4. 独立评审与修正

按改动选评审方式,协议都在 视觉评审协议:

改动 评审
方向探索阶段的对比页 先交给用户;推荐每个小样评审一轮、多方向再加一次横向评审,说明能改善什么、要多少时间,由用户决定
新界面、整体改版,选定方向之后 截图、评审、修改循环,10 分制,目标 9 分,默认最多三轮
已有界面润色一整页以上,或只要求评审现有界面 “给已有界面评审”,一轮,不打分
存量项目里优化 UI、改流程、加新功能 按 存量项目 的“各类改动怎样评审”
单个组件 按 组件 的“打磨轮次”
小改动、局部低风险修改 主 Agent 自己看,不派评审者
  • 有隔离、能看图的执行者时,派一个没有历史上下文的评审者;没有就自检,并标明未独立评审。评审者只看当前画面、任务和约束,不看制作过程和代码。
  • 新界面或改动了操作流程时,另做一次任务走查,和视觉评分分开判断;单个组件不做。
  • 评分循环在这些情况下停止:到 9 分、连续两轮没有提升、到达轮次上限,或者连续两轮的最大差距都指向骨架常见、认不出是谁家,这时换方向或停下写明原因,不耗完三轮。风格开始漂移、意见反复时,保留最合适的版本并说明取舍;没完成的必需功能照实列出。
  • 用户反复不满意写代码做出的设计、宿主又能生成图片时,可以建议先用 draw-ui 生成设计图,挑中再照图实现;同一次对话只提一次。
  • 并行制作时按独立页面、素材或方向分工,不让多个执行者同时改同一份共享样式。

5. 验证与交付

检查深度跟着改动走:小改动只看改动处和相邻元素;精修和基线做前后对比;新页面、改版和局部重构做下面全部检查。

  • 交互从真实入口走到可观察结果;保存后重新读取,失败后检查输入和当前位置是否保留。

  • 只跑项目的类型检查和 lint,不跑生产构建和全量测试,用户要求时除外。构建失败、接口报错、依赖链接这类和画面无关的环境问题,在交付说明里记一行后绕过,不排查、不改项目配置。

  • 按 视觉语言 过三遍:“克制”一节做减法,一页只有一个主角,逐区块删一轮文字;“细节”一节在 100% 和 200% 下看形状、对齐和状态;“模型默认审美自查”看整页截图,出现三项以上没有理由的默认做法,回到方向重定主构图。减法只删装饰和重复,对象名称、判断依据、当前状态和主动作必须留下。

  • 交付前对一遍,交付说明里逐项写到:

    • 选定的方向和理由;
    • 改了什么,哪些没做、为什么;
    • 每轮评分,或者写明没有评审;
    • 删掉了哪些文字;
    • 证据文件在任务目录的哪里。

    设计说明、素材、截图和评审记录放在任务目录,不写进 Skill 安装目录。

能力边界

没有看图能力时可以产出设计说明、实现代码或源码层面的检查,但明确“未验证实际视觉”,不生成虚假的视觉评分。没有可运行环境时不能声称交互通过;请求要求可运行界面却只能交付方案时,明确标为未完成部分。

没有生成能力时优先使用已有合适素材,或交付明确的素材需求和可用占位版本。只使用任务已授权的服务与配置,不因缺少素材自动接入付费服务;本 Skill 不管理密钥、安装工具或发布网站。网络不可用时使用已有参考,并说明来源范围。