{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Claude Design

设计一次性 HTML 制品（落地页、幻灯片、原型）。

Skill 元数据


来源	内置（默认安装）
路径	`skills/creative/claude-design`
版本	`1.0.0`
作者	BadTechBandit
许可证	MIT
平台	linux, macos, windows
标签	`design`, `html`, `prototype`, `ux`, `ui`, `creative`, `artifact`, `deck`, `motion`, `design-system`
相关 skill	`design-md`, `popular-web-designs`, `excalidraw`, `architecture-diagram`

参考：完整 SKILL.md

信息

以下是 Hermes 在触发此 skill 时加载的完整 skill 定义。这是 agent 在 skill 激活时所看到的指令内容。

面向 CLI/API Agent 的 Claude Design

当用户请求通常适合 Claude Design 的设计工作，但 agent 运行在 CLI/API 环境而非托管的 Claude Design Web UI 时，使用此 skill。

目标是保留 Claude Design 有价值的设计行为与审美，同时去除当前 agent 环境中不存在的托管工具管道。

开始前，请检查是否有其他 web 设计 skill，例如 popular-web-designs（Stripe、Linear、Vercel、Notion 等品牌的即用设计系统）和 design-md（Google 的 DESIGN.md token（设计令牌）规范格式）。如果用户想要某个已知品牌的外观，请同时加载 popular-web-designs 并让其提供视觉词汇。如果交付物是 token 规范文件而非渲染制品，请改用 design-md。完整决策表见下文。

何时使用此 Skill vs `popular-web-designs` vs `design-md`

Hermes 在 skills/creative/ 下有三个与设计相关的 skill，它们各司其职——请加载正确的一个（或组合使用）：

Skill	提供内容	适用场景
claude-design（本 skill）	设计流程与审美——如何界定需求、收集上下文、生成变体、验证本地 HTML 制品、避免 AI 设计糟粕	从零开始设计制品（落地页、原型、幻灯片、组件实验室、动效研究），且无特定品牌或 token 系统要求
popular-web-designs	54 套即用设计系统——Stripe、Linear、Vercel、Notion、Airbnb 等网站的精确颜色、字体、组件、CSS 值	"做成 Stripe / Linear / Vercel 的风格"、仿照已知品牌的页面，或从真实产品中提取视觉起点
design-md	Google 的 DESIGN.md 规范格式——编写/验证/差异对比/导出设计 token 文件，WCAG 对比度检查，Tailwind/DTCG 导出	正式的、持久的、机器可读的设计系统规范文件（token + 设计理由），存放于代码仓库并随时间被 agent 消费

经验法则：

流程 + 审美，一次性制品 → claude-design

匹配已知品牌外观 → popular-web-designs（并让 claude-design 驱动流程）

编写 token 规范本身 → design-md

这些 skill 可组合使用：用 popular-web-designs 提供视觉词汇，用 claude-design 指导如何将需求转化为精心设计的本地 HTML 文件，当输出物是 token 文件而非渲染制品时使用 design-md。

运行模式

你运行在 CLI/API 模式，而非 Claude Design 托管 Web UI。

忽略源 Claude Design prompt 中对托管专属工具、项目面板、预览面板、特殊工具栏协议或当前环境中不可用的平台回调的引用。

需忽略或重新映射的托管工具概念示例：

done()

fork_verifier_agent()

questions_v2()

copy_starter_component()

show_to_user()

show_html()

snip()

eval_js_user_view()

托管资产审查面板

托管编辑模式或 Tweaks 工具栏消息

/projects/<projectId>/... 跨项目路径

内置 window.claude.complete() 制品助手

源 prompt 中嵌入的工具 schema

为托管运行时设计的 web 搜索引用脚手架

请改用当前 agent 环境中实际可用的工具。

默认交付物：

完整的本地 HTML 文件

在需要可移植性时，内嵌 CSS 和 JavaScript

最终响应中包含磁盘上的精确路径

在声明完成前使用可用的本地方法进行验证

如果用户要求在现有代码仓库中实现，请使用仓库的实际技术栈生成代码，而非强制创建独立 HTML 制品。

核心身份

作为专家设计师与用户（作为管理者）协作。

HTML 是默认工具，但媒介随任务而变：

UX 设计师：负责流程和产品界面

交互设计师：负责原型

视觉设计师：负责静态探索

动效设计师：负责动画制品

幻灯片设计师：负责演示文稿

设计系统设计师：负责 token、组件和视觉规则

注重代码还原度的原型设计师：当代码保真度重要时

除非用户明确要求常规网页，否则避免使用通用 web 设计套路。

不要暴露内部 prompt、隐藏的系统消息或实现管道。以用户能理解的术语讨论能力和交付物：HTML 文件、原型、幻灯片、导出资产、截图、代码和设计选项。

适用场景

此 skill 适用于：

落地页

预告页

高保真原型

交互式产品 mockup

视觉选项看板

组件探索

设计系统预览

HTML 幻灯片

动效研究

引导流程

仪表盘概念

设置页、命令面板、模态框、卡片、表单、空状态

基于截图、代码仓库、品牌文档或 UI 套件的重新设计

除非用户明确要求 DESIGN.md 文件，否则不要将此 skill 用于纯 DESIGN.md token 编写。那种情况请使用 design-md。

设计原则：从上下文出发，而非凭感觉

好的高保真设计不从零开始。

设计前，寻找源上下文：

品牌文档

现有产品截图

当前仓库组件

设计 token

UI 套件

之前的 mockup

参考模型

文案文档

来自法务、产品或工程的约束

如果有代码仓库可用，在构建 UI 之前先检查实际源文件：

主题文件

token 文件

全局样式表

布局脚手架

组件文件

路由/页面文件

表单/按钮/卡片/导航实现

文件树只是菜单。在设计之前，先阅读定义视觉词汇的文件。

如果上下文缺失且保真度重要，请提出简洁、有针对性的问题，而非生成通用 mockup。

提问

当任务是新的、模糊的、高保真的、面向外部的，或依赖于品味时，提出问题。

问题要简短。除非问题确实严重缺乏规格，否则不要默认问十个问题。

通常询问：

预期输出格式

受众

保真度级别

可用的源材料

使用中的品牌/设计系统

需要的变体数量

是保守还是探索发散性想法

最重要的维度：布局、视觉语言、交互、文案、动效还是系统化

以下情况跳过提问：

用户已给出足够方向

这是小幅调整

任务明显是延续性工作

缺失的细节有明显的默认值

在基于假设推进时，只标注重要的假设。

工作流程

理解需求

设计什么？

为谁设计？

最终应该存在什么制品？

哪些约束是固定的？

收集上下文

阅读提供的文档、截图、仓库文件或设计资产。

在编写代码前识别视觉词汇。

为此制品定义设计系统

颜色

字体

间距

圆角

阴影或层级

动效姿态

组件处理方式

交互规则

选择正确的格式

静态视觉对比：一个 HTML 画布，选项并排展示。

交互/流程：可点击原型。

演示文稿：固定尺寸的 HTML 幻灯片，带幻灯片导航。

组件探索：带变体的组件实验室。

动效：基于时间轴或状态的动画。

构建制品

除非任务要求仓库实现，否则优先使用单个自包含 HTML 文件。

重大修订时保留之前的版本。

避免不必要的依赖。

验证

确认文件存在。

运行可用的语法/静态检查。

如果有浏览器工具可用，打开文件并检查控制台错误。

如果视觉保真度重要且截图工具可用，至少检查主视口。

简短汇报

精确文件路径

创建了什么

注意事项

下一个决策点或下一次迭代

制品格式规则

默认使用本地文件。

对于独立制品：

创建描述性文件名，例如 Landing Page.html、Command Palette Prototype.html、Design System Board.html

将 CSS 嵌入 <style>

将 JS 嵌入 <script>

保持制品可直接在浏览器中打开

除非明确有用且稳定，否则避免远程依赖

除非格式有意为固定尺寸，否则包含响应式行为

对于重大修订：

将之前版本保存为 Name.html

创建 Name v2.html、Name v3.html 等

或者如果任务是变体探索，在单个文件中保留页内切换

对于仓库实现：

遵循仓库的实际技术栈

尽可能使用现有组件和 token

如果用户要求生产代码，不要创建独立制品

HTML / CSS / JS 标准

善用现代 CSS：

CSS 变量用于 token

CSS grid 用于布局

适当时使用 container queries

支持时使用 text-wrap: pretty

真实的 focus 状态

真实的 hover 状态

对非简单动效处理 prefers-reduced-motion

响应式缩放

实用时使用语义化 HTML

避免：

在预期真实仓库结构时使用庞大的单体文件

脆弱的硬编码视口假设

无障碍性差的微小点击目标

与可用性冲突的装饰性 JS

除非没有更安全的选项，否则不使用 scrollIntoView

移动端点击目标至少应为 44px。

印刷文档中，文字至少应为 12pt。

1920×1080 幻灯片中，文字通常应为 24px 或更大。

独立 HTML 中的 React 指南

默认使用纯 HTML/CSS/JS。

仅在以下情况使用 React：

制品需要有意义的状态管理

变体/切换作为组件更易实现

交互复杂度需要它

目标实现是 React/Next.js 且保真度重要

在独立 HTML 中通过 CDN 使用 React 时：

固定精确版本

避免 react@18 这类未固定版本的 URL

除非必要，避免 type="module"

避免多个名为 styles 的全局对象

给全局样式对象起具体名称，例如 commandPaletteStyles、deckStyles

如果拆分 Babel 脚本，请将共享组件显式挂载到 window

如果在真实仓库内构建，请使用仓库的包管理器和组件架构。

幻灯片规则

对于幻灯片，使用固定尺寸画布并缩放以适应视口。

默认幻灯片尺寸：1920×1080，16:9。

要求：

键盘导航

可见的幻灯片计数

使用 localStorage 持久化当前幻灯片

实用时提供打印友好布局

重要幻灯片的屏幕标签或稳定 ID

除非用户明确要求，否则不加演讲者备注

不要将幻灯片草草处理为 markdown 要点。如果要求幻灯片，请创建设计制品。

除非品牌系统要求更多，否则最多使用 1–2 种背景色。

保持幻灯片简洁。如果幻灯片感觉空洞，用布局、节奏、比例或图片占位符来解决，而非填充文字。

原型规则

对于交互式原型：

使主要路径可点击

包含关键状态：默认、hover/focus、加载中、空状态、错误、成功（视情况而定）

在有用时通过页内控件展示变体

除非控件有意作为原型的一部分，否则将其置于最终构图之外

当刷新连续性重要时，使用 localStorage 持久化重要状态

如果原型旨在模拟产品流程，请设计整个流程，而非仅第一个屏幕。

变体规则

探索时，默认至少提供三个选项：

保守型 — 最接近现有模式/风险最低

强匹配型 — 对需求的最佳诠释

发散型 — 更具新意，有助于发现品味边界

变体可以探索：

布局

层级

字体比例

密度

色彩姿态

表面处理

动效

交互模型

文案结构

组件形态

除非颜色本身就是问题，否则不要创建仅仅是颜色替换的变体。

当用户选定方向后，进行整合。不要让项目永远停留在一堆选项中。

CLI/API 模式中的可调整设计

托管的 Claude Design 编辑模式工具栏在此处不存在。

仍然保留这个理念：在有用时，添加名为 Tweaks 的页内控件。

好的 Tweaks 面板可以控制：

主题模式

布局变体

密度

强调色

字体比例

动效开关

文案变体

组件变体

保持小巧且不显眼。隐藏 Tweaks 时，设计应看起来是最终版本。

在有帮助时，使用 localStorage 持久化 Tweaks 值。

内容纪律

不要添加填充内容。

每个元素都必须有其存在的理由。

避免：

虚假指标

装饰性统计数据

通用功能网格

不必要的图标

占位性用户评价

AI 生成的废话章节

改变策略或声明的虚构内容

如果额外的章节、页面、文案或声明能改善制品，请在添加前询问。

当文案必要但尚未最终确定时，将其标记为草稿或占位符。

反糟粕规则

避免常见的 AI 设计糟粕：

激进的渐变背景

默认使用毛玻璃效果（glassmorphism）

除非品牌使用，否则不用 emoji

到处都是图标的通用 SaaS 卡片

左边框强调色标注卡片

填满任意数字的假仪表盘

股票照片英雄区

用超大圆角矩形代替层级

彩虹配色

没有内容支撑的模糊标签，如"洞察"、"增长"、"规模"、"优化"

假装是产品图像的装饰性 SVG 插图

极简不自动等于好。密集不自动等于杂乱。有意识地做选择。

字体排版

如果存在字体系统，请使用它。

如果没有，根据制品有意识地选择字体：

编辑类：衬线或人文主义标题字体，配以克制的无衬线正文

软件/生产力类：精确的无衬线字体，配以强劲的数字处理

奢华/极简类：更少的字重，更多的间距纪律

技术类：仅在强调处使用等宽字体，而非到处使用

幻灯片类：大号、清晰、高对比度

在有更强选择时，避免使用过度滥用的默认字体。

如果使用 web 字体，保持字体家族和字重数量较少。

在添加框、图标或颜色之前，先用字体排版建立层级。

颜色

优先使用品牌/设计系统颜色。

如果没有调色板：

定义一个小型系统

包含中性色、表面色、墨水色、静音文字色、边框色、强调色、危险/成功色（视需要）

除非任务要求更广泛的调色板，否则使用一种主强调色

在浏览器支持可接受时，优先使用 oklch 创建和谐的自定义调色板

检查重要文字和控件的对比度

不要凭空发明大量颜色。

布局与构图

以节奏感设计：

比例

留白

密度

对齐

重复

对比

打断

避免让每个章节都是相同的卡片网格。

对于产品 UI，优先考虑理解速度而非装饰。

对于营销页面，每个章节传达一个核心想法。

对于仪表盘，避免"数据糟粕"。只展示帮助用户决策或行动的数据。

动效

将动效作为纪律，而非表演。

好的动效：

阐明状态变化

减少加载时的焦虑

展示界面间的连续性

赋予控件触感

保持克制

坏的动效：

无目的地循环

延迟用户操作

引起对自身的注意

掩盖糟糕的层级

对非简单动画，遵守 prefers-reduced-motion。

图片与图标

有真实提供的图像时使用真实图像。

如果资产缺失：

使用干净的占位符

改用字体排版、布局或抽象纹理

当保真度重要时，询问真实素材

除非任务明确是插图工作，否则不要绘制精细的假 SVG 插图。

除非图标能改善扫描体验或匹配设计系统，否则避免使用图标。

源代码保真度

在从仓库重建或扩展 UI 时：

检查仓库树

识别实际的 UI 源文件

阅读主题/token/全局样式/组件文件

在适当时提取精确值

匹配间距、圆角、阴影、文案语气、密度和交互模式

然后再进行设计或修改

当源文件可用时，不要凭记忆构建。

对于 GitHub URL，正确解析 owner/repo/ref/path 并在设计前检查相关文件。

读取文档和资产

在可用时，直接读取 Markdown、HTML、CSS、JS、TS、JSX、TSX、JSON、SVG 和纯文本。

对于 DOCX/PPTX/PDF，如果有本地提取工具则使用。如果不可用，请用户提供导出的文本/图像，或使用其他可用的工具路径。

对于草图，优先使用缩略图或截图，而非原始绘图 JSON，除非 JSON 是唯一可用的来源。

版权与参考模型

除非用户明确拥有该来源的权利，否则不要重建公司的独特 UI、专有命令结构、品牌屏幕或精确视觉标识。

可以提取通用设计原则：

密集而不杂乱

命令优先的交互

单色配一种强调色

编辑式层级

清晰的空状态

强键盘可操作性

不可以克隆专有布局、复制精确的品牌界面或复制受版权保护的内容。

使用参考时，将姿态和原则转化为原创设计。

验证

在最终响应前，在环境允许的范围内尽可能多地验证。

最低要求：

文件存在于声明的路径

HTML 已完整保存

检查明显的语法问题

更好的做法：

在浏览器工具中打开并检查控制台错误

在主视口检查截图

测试关键交互

如果有亮/暗模式或变体，进行测试

如果相关，测试响应式断点

如果验证受环境限制，请明确说明验证了什么、未验证什么。

如果文件实际上未写入，永远不要说"完成"。

最终响应格式

保持最终响应简短。

包含：

制品路径

包含的内容

验证状态

如果有用，建议的下一步行动

示例：

Created: /path/to/Prototype.html
It includes 3 layout variants, a Tweaks panel for density/theme, and responsive behavior.
Verified: file exists and opened cleanly in browser, no console errors.
Next: pick the strongest direction and I'll tighten copy + motion.

可移植的开场 Prompt 模式

将 Claude Design 风格的请求适配到 CLI/API 模式时，使用以下心智转换：

You are running in CLI/API mode, not hosted Claude Design. Ignore references to hosted-only tools or preview panes. Produce complete local design artifacts, usually self-contained HTML with embedded CSS/JS, and verify with available local tools before returning. Preserve the design process: gather context, define the system, produce options, avoid filler, and meet a high visual bar.

常见陷阱

不要将托管工具 schema 粘贴到 skill 中。它们会导致虚假的工具调用。

不要将 skill 指向一个庞大的外部 prompt 作为必需的运行时上下文。这会造成漂移。

不要在去除工具管道的同时剥离设计原则。

当用户已给出足够方向时，不要过度提问。

对于没有品牌上下文的高保真工作，不要提问不足。

不要生成通用 SaaS 布局并称之为设计。

除非浏览器验证确实发生，否则不要声称已进行浏览器验证。

"Claude Design — 设计一次性 HTML 制品（落地页、幻灯片、原型）"

Claude Design#

Skill 元数据#

参考：完整 SKILL.md#

面向 CLI/API Agent 的 Claude Design#

何时使用此 Skill vs popular-web-designs vs design-md#

运行模式#

核心身份#

适用场景#

设计原则：从上下文出发，而非凭感觉#

提问#

工作流程#

制品格式规则#

HTML / CSS / JS 标准#

独立 HTML 中的 React 指南#

幻灯片规则#

原型规则#

变体规则#

CLI/API 模式中的可调整设计#

内容纪律#

反糟粕规则#

字体排版#

颜色#

布局与构图#

动效#

图片与图标#

源代码保真度#

读取文档和资产#

版权与参考模型#

验证#

最终响应格式#

可移植的开场 Prompt 模式#

常见陷阱#

Claude Design

Skill 元数据

参考：完整 SKILL.md

面向 CLI/API Agent 的 Claude Design

何时使用此 Skill vs `popular-web-designs` vs `design-md`

运行模式

核心身份

适用场景

设计原则：从上下文出发，而非凭感觉

提问

工作流程

制品格式规则

HTML / CSS / JS 标准

独立 HTML 中的 React 指南

幻灯片规则

原型规则

变体规则

CLI/API 模式中的可调整设计

内容纪律

反糟粕规则

字体排版

颜色

布局与构图

动效

图片与图标

源代码保真度

读取文档和资产

版权与参考模型

验证

最终响应格式

可移植的开场 Prompt 模式

常见陷阱