该技能用于对现有界面做纯 UI/UX 改动，走一条比完整工作流更短的路径。它强调视觉改动的真正验收者是人眼，因此只安排两个会话，而不是五个或更多。
用途与范围 改动的只是屏幕的外观与感受，不触碰底层。判定标准是差异是否仅涉及呈现层：标记、样式、布局、文案、图标、间距、动效，以及只改变外观的组件属性；不改变读取或写入的数据、API 调用、持久状态、校验、路由与权限。范围门需检查两次：选定方向时检查一次，提交前用 git diff --stat 再检查一次。若越界，则停止当前流程，把选定的视觉稿及其截图复制到 .workflow/<slug>/prototypes/P1-<name>/ 与 screens/，在 design.md 中写明原因并标记 Status: handed over，转到工作流的 brainstorm 卡片，把该原型作为已有决定的证据，不再重问选择。
主要能力与流程 命令 design <slug> - goal: <说明哪里应看起来或感觉不同> 开启第一个会话（设计席），依次执行：
- 摸底：阅读 DESIGN.md 中本屏用到的标题与章节、文案改动时读 PRODUCT.md §Vocabulary、本屏自身的组件与样式；通过仓库的 verify-* 技能（.agents/skills/verify-/）或本 CLI 可用的任意浏览器工具，在 1280 与 375 两种宽度下截取当前界面到 screens/before-.jpg；若应用在此处无法运行，可一次性询问人工提供截图或先不带截图开始，并在 design.md 中说明。完成标准是能说出该屏的令牌（颜色、字号层级、间距、圆角）及其真实内容。
- 探索：构思 2-3 个在理念而非色调上不同的方向，差异体现在布局、密度、层级、分组、交互；每个方向都要回应目标，其中一个贴近现有设计以便看出改动成本。每个方向做成静态 HTML，放在 mockups/M#-<name>/index.html，使用仓库真实令牌，并复制界面上的真实标签与数值，避免虚构内容让视觉稿优于实际产品。若本 CLI 有图像工具且某方向重在氛围而非布局，可在 HTML 旁附一张生成图。每个方向在两种宽度下截图到 screens/m#-<width>.jpg，并编写 mockups/compare.html：改动前界面与各方向并排，每列一个，各配一行理念说明。
- 选定：一轮提问，把各方向连同截图路径作为选项，推荐项排在最前并说明其为何最贴合目标；人工可混搭（如“b 的布局、a 的密度”），混搭需先合并为一个方向再实施；选定后检查范围门。
- 构建：以最小差异把选定方案应用到真实代码，复用仓库现有组件与令牌；新增令牌或组件需在 design.md 中注明并在同一提交内加入 DESIGN.md。先构建屏幕主区域并截图，再处理其余部分，以降低走错方向的成本；随后把差异触及的每个屏幕在两种宽度下截图到 screens/after-*.jpg，检查底线与范围门。
- 试用与提交：向人工提供启动命令、路由与需查看之处；在人工确认可用后，将代码、DESIGN.md 与 .design/<slug>/ 一并提交，Status: built。推送前用 gitleaks git --log-opts="@{u}..HEAD" --redact -v --no-banner 扫描，仅在退出码为 0 时推送。
第二个会话由命令 design check <slug> 触发（新鲜视角席，独立新会话）：只读 design.md 的 Goal 与 Pick 两行、选定视觉稿的截图，以及改动前后的截图，其余（代码、其他视觉稿、design.md 其他部分）在写出发现前保持关闭；随后运行 git diff --stat <Base>..HEAD 检查范围门。在 design.md 的 ## Check 下最多写 8 行，每行属于三类之一：drift（改动后界面与选定方案不符，或改了目标未要求的内容）、floor（底线某条不通过）、craft（间距、对齐、层级或状态显得未完成），每行需指明截图及其位置。询问要修哪些，优先 drift 与 floor；修复后重新截图，由人工试用，以 Status: done 提交。需要逻辑变更的发现不在此处修复，而是移交工作流。
底线（任何视觉稿与改动后界面都须满足，设计理由不能凌驾其上） 文本对比度至少 4.5:1，大字号文本与控件至少 3:1；每个交互元素都有可见焦点态且可键盘到达；动效遵循 prefers-reduced-motion；375 宽布局无横向滚动、无文本裁切、点击目标不小于 44 px；内容为产品自身真实标签、数值与状态；界面已有的空、加载、错误状态仍具设计感。
产物与记录 .design/<slug>/ 受 git 跟踪并保留，与 .workflow/ 分属不同根，避免工作流状态机与 check-run.py 误判为未完成运行。目录内含 design.md（记录，约 40 行以内）、mockups/（每个方向一个自包含 index.html，旁附 compare.html）、screens/（before-.jpg、m1-.jpg、after-*.jpg，各含 1280 与 375 宽度）。design.md 有默认模板，记录命令、创建日期与模型、基准 sha、状态（exploring | built | done | handed over）、所读文档、目标、屏幕、方向、选定及理由、已构建文件与新增令牌/组件、与选定方案的差异、底线结果等；仓库有 WORKLOG.md 时在完成时追加一行记录。
提问与模型 人工可读的一切遵循 plain 技能的规则：首条消息前调用一次；提问沿用工作流形式：每次一个决定、字母选项、推荐项置前并加粗、每个选项附理由。文中给出的模型配置为：设计席使用 Anthropic · Opus 5.5 · high；新鲜视角使用另一厂商 OpenAI · GPT-6.1 Terra · medium（选择器 ID gpt-6.1-terra），因其视觉推理能力且价格约为前者的十分之一；当 workflow/ROUTING.md 中存在名为 Design 与 Design check 的行时，以这些行为准。
适用场景与限制 适合对已有界面做外观层面的快速迭代，并希望通过独立复核控制视觉偏差。限制在于：范围严格限于呈现层，逻辑变更须移交完整工作流；依赖仓库文档、组件令牌、截图工具与人工试用确认；应用无法在当前环境运行时需人工提供截图或明确记录缺失。不同版本的模型与路由配置以仓库中的 ROUTING.md 为准。