Files
workbuddy_skills/oil-ui-pro/SKILL.md
T
admin 9721876f08 新增两个技能(product-planning / oil-ui-pro)+ 作业规矩交叉引用跟到新落点
一、新增技能
- product-planning(253 文件):四阶段产品方案流水线(调研方案 / 需求结构 / 界面交付 / 说明文档),
  含 references/stage-* 与内置的 diagram-design 子技能、scripts/
- oil-ui-pro(26 文件):UI/UX 设计 · 评审 · 多风格对比,含 assets/style-explorer.html、scripts/shoot.mjs、tests/

二、session-mechanism 收尾(承接 e5dfb6e)
- references/作业规矩/03-多棒接力编排.md、04-去AI味与说话方式.md:交叉引用表里的「参考 01」改为新落点
  (该不该问/结论骨架 → references/02-功能优先协作协议.md;回复排版 → references/03-回复排版-核心块.md)
- references/manifest.md 随生成器重算(含上述两行的 md5 与字节数)

三、入库前检查
- 三个技能内均无令牌 / 私钥 / 密钥赋值;.neodata_token 类落点已由 .gitignore 挡住
- 无运行期产物混入(logs/ · tmp/ · __pycache__ · *.log)
- 暂存 282 个文件 = 279 新增(253 + 26)+ 3 修改
2026-10-07 00:48:07 +08:00

124 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
name: oil-ui-pro
description: "设计、改进和评审网站、App、后台与组件的 UI/UX,完成设计方向探索、多风格同屏比较、视觉层级、任务流程、状态反馈、响应式布局和基于实际画面的迭代;按请求交付对比页、设计说明、设计稿或可运行界面。当用户需要新界面设计、比较不同设计风格、已有界面体验优化、视觉精修、截图还原或 UI/UX 评审时使用。只负责设计与体验判断,组件归属、数据流、状态正确性和测试等代码实现质量不在范围内。不用于纯业务逻辑、接口、构建部署、无界面行为变化的代码整理、单独绘制普通插画或操作现有网站。"
allowed-tools:
- Bash(sh *check_update.sh*)
- Bash(python3 *check_update.py*)
- Bash(python *check_update.py*)
- Bash(py -3 *check_update.py*)
metadata:
version: "0.15.4"
compatibility: "核心为宿主中立的文本流程,不依赖其他 Skill 或指定模型。可选风格对比页生成器需要 Python 3.10+ 标准库,产物仅需现代浏览器;本机地址候选需要对应的本地开发服务器在运行。实际视觉验收需要看图能力;交互验收需要可操作环境;独立评审需要隔离上下文且能看图的执行者。"
---
# oil-ui-pro
以明确的设计北极星组织界面,让构图、字体、色彩、素材和交互相互呼应,形成有辨识度的表达。克制是保留最有力量的选择、删除无贡献的元素,不是把所有风格磨成中庸。视觉表现与任务完成分别验收。
风格从这个页面的品类、首屏的主角和这个品牌里推出来,不从模型的默认模板里长出来。动手前先回答三件事:它是什么品类;用户来首屏看什么、做什么;同类最好的产品在首屏和控件上是怎么做的。方向只在这之上偏离,偏离要说得出来自这个产品的理由。
方法和评审协议均在本目录内,直接使用宿主提供的文件、浏览、看图、生成与隔离执行能力;不要求加载其他 Skill。截图、录屏、状态并排和遮字图用本目录的截图工具,写可操作小样的方式也在同一处,见 [工具](references/tools.md);不为取证另外加载浏览器类 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 进入,只检查受影响的区域与状态 |
| 单个组件,要打磨到极致或做出辨识度 | 读 [组件](references/component.md)。组件在存量项目里时,样式按 [存量项目](references/existing-project.md) 的“从源头修改”落到现有变量和组件上 |
| 存量项目里优化 UI、改流程或加新功能 | 读 [存量项目](references/existing-project.md),先分清是哪一种。改流程和加新功能不走步骤 1 的视觉方向探索,但本文开头的三问照答 |
| 截图还原 | 按 [布局与视口](references/layout-and-viewport.md) 的“精准还原”,以参考图为视觉基线,确定参考视口与布局约束后进入步骤 2,不发散新风格 |
| UI/UX 评审 | 按问题读取对应参考,只做步骤 4 的诊断,交付证据与建议 |
## 1. 探索并收敛方向
方向未确定时按 [设计方向](references/design-direction.md) 走:认品类、拆标杆、定调性、起方向,写文案之前先定首屏骨架;多个方向时填方向卡、做差异检验。小样只做首屏和最能体现方向的一两个区块,方案数量按任务定。需要并排比较时,用 [风格对比页](references/style-explorer.md) 的模板和生成器。
方向由用户的品味来定:给出对比页和推荐理由,请用户选定,再说出具体喜欢和不喜欢哪里,按反馈收紧后再深化。用户让你自己决定或无法交互时,仍先出对比页留档,再选定并写明理由。
留一份简短的设计说明:用户任务、主动作、选定方向、关键状态、设备约束和验收重点。已有说明直接更新。
## 2. 建立视觉与交互结构
根据当前决策按需读取,不预先加载全部参考:
| 要解决的问题 | 参考 |
| --- | --- |
| 视觉层级、字体、色彩、空间、图标、风格统一或减法精修 | [视觉语言](references/visual-language.md) |
| 用户流程、文案、动作、表单、选择、状态与失败恢复 | [交互与状态](references/interaction-and-state.md) |
| 页面、分栏、弹窗、浮层、滚动、响应式或截图还原 | [布局与视口](references/layout-and-viewport.md) |
| 素材选择、视频与 3D | [素材](references/media.md) |
| 生成配图:让图承担意思、写提示词、和页面接成一体 | [配图](references/imagery.md) |
| 三处基本动效与呼应、动效手感、界面过渡、首屏动画与滚动叙事、时长与检查 | [动效](references/motion.md) |
| 点缀与特效:流动渐变、流光、点阵、颗粒、SVG 线条与排字 | [点缀与特效](references/ornament.md) |
新产品要交代主要内容的层级和关键操作链,不只做漂亮的默认状态。新界面和改动了操作流程时,按 [动效](references/motion.md) 做出三处基本动效;小改动不加。
构图阶段先按 [素材](references/media.md) 判断图像能否承担主信息或情绪重心。需要关键素材时先选定或制作它,再围绕它安排文字和操作,不等布局填满后再补图。
既有项目先复用有效的设计变量、组件和交互习惯,修问题从源头修,不为一次调整另造设计系统,也不把无关代码重构混入视觉工作。具体做法见 [存量项目](references/existing-project.md)。
## 3. 制作并取得实际证据
- 先完成代表性页面或关键操作链,检查后再延展到其他页面。
- 示例内容按真实产品的样子写。模拟数据、生成图片、未接入的动作写在交付说明里,不写进界面:画面上不出现“示例”“示意图”“按钮未接入”“仅保存在本机”这类制作说明。不伪造业务成功、客户评价或产品指标。
- 在目标视口运行并查看,用 [工具](references/tools.md) 里的截图工具取证:涉及的状态、200% 局部、动效的录屏或开始、中间、结束三帧。只有静态截图,证明不了动效。
- 在实际阅读尺寸检查中文多行标题、正文和窄屏换行。文字重叠、被裁切或靠大量小字才装得下时,回到内容和布局修,不靠缩放掩盖。长页要检查整体节奏,不能只看首屏。截图保存成功不等于已经看过。
## 4. 独立评审与修正
按改动选评审方式,协议都在 [视觉评审协议](references/visual-review.md):
| 改动 | 评审 |
| --- | --- |
| 方向探索阶段的对比页 | 先交给用户;推荐每个小样评审一轮、多方向再加一次横向评审,说明能改善什么、要多少时间,由用户决定 |
| 新界面、整体改版,选定方向之后 | 截图、评审、修改循环,10 分制,目标 9 分,默认最多三轮 |
| 已有界面润色一整页以上,或只要求评审现有界面 | “给已有界面评审”,一轮,不打分 |
| 存量项目里优化 UI、改流程、加新功能 | 按 [存量项目](references/existing-project.md) 的“各类改动怎样评审” |
| 单个组件 | 按 [组件](references/component.md) 的“打磨轮次” |
| 小改动、局部低风险修改 | 主 Agent 自己看,不派评审者 |
- 有隔离、能看图的执行者时,派一个没有历史上下文的评审者;没有就自检,并标明未独立评审。评审者只看当前画面、任务和约束,不看制作过程和代码。
- 新界面或改动了操作流程时,另做一次任务走查,和视觉评分分开判断;单个组件不做。
- 评分循环在这些情况下停止:到 9 分、连续两轮没有提升、到达轮次上限,或者连续两轮的最大差距都指向骨架常见、认不出是谁家,这时换方向或停下写明原因,不耗完三轮。风格开始漂移、意见反复时,保留最合适的版本并说明取舍;没完成的必需功能照实列出。
- 用户反复不满意写代码做出的设计、宿主又能生成图片时,可以建议先用 [draw-ui](https://github.com/oil-oil/draw-ui) 生成设计图,挑中再照图实现;同一次对话只提一次。
- 并行制作时按独立页面、素材或方向分工,不让多个执行者同时改同一份共享样式。
## 5. 验证与交付
检查深度跟着改动走:小改动只看改动处和相邻元素;精修和基线做前后对比;新页面、改版和局部重构做下面全部检查。
- 交互从真实入口走到可观察结果;保存后重新读取,失败后检查输入和当前位置是否保留。
- 只跑项目的类型检查和 lint,不跑生产构建和全量测试,用户要求时除外。构建失败、接口报错、依赖链接这类和画面无关的环境问题,在交付说明里记一行后绕过,不排查、不改项目配置。
- 按 [视觉语言](references/visual-language.md) 过三遍:“克制”一节做减法,一页只有一个主角,逐区块删一轮文字;“细节”一节在 100% 和 200% 下看形状、对齐和状态;“模型默认审美自查”看整页截图,出现三项以上没有理由的默认做法,回到方向重定主构图。减法只删装饰和重复,对象名称、判断依据、当前状态和主动作必须留下。
- 交付前对一遍,交付说明里逐项写到:
- 选定的方向和理由;
- 改了什么,哪些没做、为什么;
- 每轮评分,或者写明没有评审;
- 删掉了哪些文字;
- 证据文件在任务目录的哪里。
设计说明、素材、截图和评审记录放在任务目录,不写进 Skill 安装目录。
## 能力边界
没有看图能力时可以产出设计说明、实现代码或源码层面的检查,但明确“未验证实际视觉”,不生成虚假的视觉评分。没有可运行环境时不能声称交互通过;请求要求可运行界面却只能交付方案时,明确标为未完成部分。
没有生成能力时优先使用已有合适素材,或交付明确的素材需求和可用占位版本。只使用任务已授权的服务与配置,不因缺少素材自动接入付费服务;本 Skill 不管理密钥、安装工具或发布网站。网络不可用时使用已有参考,并说明来源范围。