design

用途

该技能覆盖产品外观的完整流程：设计规则、何时使用哪个外部技能、如何判断结果。它适用于设计屏幕或设计系统、选择颜色/字体/组件，或评判外观的场合，目标是与产品负责人一起设计、构建和评审产品 UI。

据资料，此前方法、技能选择、屏幕规则和评审分散在不同文件中，产品只读到部分内容就会重复他人已记录的错误；该技能将它们整合为一份。

约束顺序

负责人的话：品味及对书面规则的任何更改由负责人决定。每个视觉问题都要用产品真实令牌构建样本，并排展示，不能用文字描述。评审分流见 references/review.md。
方法（references/method.md）：每个套件和屏幕都要满足。产品偏离规则只能由负责人决定，并在套件 README 中记录原因。
产品套件：通常位于 design/ 文件夹，包含 tokens.css（所有原始值：颜色、字体、间距、圆角、时长）、kit.css（仅由令牌构建的原语）和 kit README（产品自己的设计文档：方向、调色板、字体、布局、按钮角色及各自理由，以及所有对方法的偏离）。屏幕组合套件，屏幕不得发明样式。
设计集合只提供建议（references/collections.md）：建议只能以令牌或原语形式进入代码，并记录在套件 README 中；集合与方法冲突时，方法优先。

产品在自己的仓库中携带该技能副本，位于 .claude/skills/design/，应复制而非指向。资料举例：某监控产品的套件 README 指向另一仓库的方法而未复制，结果在五处发布了方法早已禁止的无边框取消按钮（2026-10-22）。非 Claude Code 的构建器将这些视为普通文件；Codex 看不到 Claude Code 插件或技能触发，因此产品代理指令需按路径指明该文件夹。集合中教到的、下一个屏幕需要的内容要写入套件 README，而不只是留在会话中。

各阶段主导集合

方向：尚无外观、外观是问题、或需要说服力的公共页面时，由 frontend-design 主导，取以产品主题为依据的方向和计划（调色板、字体、布局、原则），在构建前对照通用默认值检查；不要让每个屏幕都产生新方向。
选项选择：调色板、字体配对、图表类型、技术栈约定等，由 UI/UX Pro Max 提供候选，手动选入套件；不要其持久化设计系统文件和安装器（避免出现第二套设计系统）。
套件：由方法结合 frontend-design 的计划，产出满足 method.md 每条规则的令牌和原语，能写测试的要有测试；排除集合提出的、方法禁止的内容。
工作型屏幕（仪表盘、管理、表格、设置）：由 Taste（design-taste-frontend）的应用屏幕运行主导，取屏幕唯一问题、每个区块的空/零/加载/错误状态、颜色只用于数据/状态/唯一主操作、最多三轮截图批评；排除其页面运行，以及套件存在时的调色板和字体。
图表：由内置 dataviz 主导，先形式后颜色、使用其调色板验证器、单轴、默认悬停；状态颜色不得复用为系列颜色。
屏幕陈述内容：见 references/screens.md 的“屏幕可以声称什么”以及 frontend-design 的写作部分，句子只能与渲染器收到的事实一样真实，每个状态摘要只用一个函数。
发布前：先按 references/screens.md 的“视觉验证什么”，再用 Impeccable，检查每个宽度、状态、主题和角色；将 Pro Max 的交付前清单作为快速检查；使用 Impeccable 的审计、加固和润色；排除 Impeccable 会自行写设计文档的命令及通过它进行的重新设计，以及用省略号代替用户输入的文字。
负责人评判外观：使用 references/review.md，提供可测量结论、真实令牌中的前后样本，并将修复与负责人的决定分开；不要没有数字的意见。
作为 claude.ai 工件发布的页面：由内置 artifact-design 主导，取其页面契约和两种主题。

collections.md 包含每个集合的细节：是什么、取什么、排除什么、如何安装，以及无需安装即可使用的检查清单。没有第三方集合时，依据方法、frontend-design 和这些清单进行设计。

负责人长期偏好（示例）

该部分应填入负责人自己的话及日期。资料中的条目是作者示例：

字重不标记状态：“颜色已经说明了这一点。两样东西说同一件事在我看来不必要。”（2026-10-22，拒绝“仅对问题加粗”）。不要为颜色、形状和文字已承载的信息再提议粗体、大小或字重作为第二信号。这与方法的“状态既是形式也是文字”规则不同：该规则是为了颜色永不成为唯一信号，属于可访问性，不是强调，仍然保留。它覆盖已存在的粗体，不仅是新提议：“每个状态相同字重”（2026-10-22）：问题徽章、值、行和名称与健康对应项使用相同字重；标题保持粗体，因为所有标题都是粗体。
应用内按钮 8 px 圆角（2026-10-22，某监控产品）。应用内按钮和分段控件取输入框与面板之间的圆角，使控件读作表单的一部分。标签在所有地方保持药丸形，因此应用内药丸表示标签而非可按压物；营销站点和公共页面可保留药丸按钮。下一个产品应用以此开始；若品牌指向别处，选择前向负责人展示两者。
监控和状态产品的目标是平静、令人安心，参考 Supabase。健康屏幕用自己的颜色说明，屏幕上没有比它更响亮地说“按下”或“当心”的内容。

如何判断有效

负责人在手机和桌面宽度查看并批准屏幕，且屏幕上每个颜色、尺寸和间距值都来自令牌。

经验记录规则

适用于任何产品：套件或构建屏幕的规则写入 method.md；屏幕声称什么或如何检查的规则写入 screens.md；评审流程更改写入 review.md。每条都附回执：日期和发生的事，产品按类型而非名称指称。能写测试的就用测试持有；只写在报告中的规则会在下一个产品消失。仅适用于本产品的内容写入其套件 README；负责人偏好写入上述部分，用其自己的话。

副本管理

每个产品携带自己的副本（.claude/skills/design/，或读取该文件夹的代理使用 .agents/skills/design/），整体复制，绝不指向。跨产品保留一份主副本，产品学到经验当天将其泛化后送回主副本。产品副本与主副本不同即表示有经验尚未送回，可用 diff -r <master>/design <product>/.claude/skills/design 查看。

文件说明

references/method.md：每个套件和屏幕满足的规则；编写或更改套件、构建任何屏幕时阅读。
references/collections.md：每个设计技能集合的取舍、安装、提炼清单；选择或运行集合，或无集合工作时阅读。
references/screens.md：屏幕可以声称什么、视觉上验证什么；更改屏幕陈述内容或发布前阅读。
references/review.md：与负责人评审已构建产品的外观；负责人评判外观或发布视觉检查时阅读。
scripts/color.py：OKLCH 亮度、色度和色相，以及 WCAG 对比度（仅标准库）；任何颜色问题都应测量而非描述。