{/* 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. */}

Sketch

一次性 HTML 原型：2-3 个设计方案对比。

Skill 元数据


来源	内置（默认安装）
路径	`skills/creative/sketch`
版本	`1.0.0`
作者	Hermes Agent（改编自 gsd-build/get-shit-done）
许可证	MIT
平台	linux, macos, windows
标签	`sketch`, `mockup`, `design`, `ui`, `prototype`, `html`, `variants`, `exploration`, `wireframe`, `comparison`
相关 skill	`spike`, `claude-design`, `popular-web-designs`, `excalidraw`

参考：完整 SKILL.md

信息

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

Sketch

当用户希望在确定方向之前先看到设计效果时使用此 skill——以一次性 HTML 原型的形式探索 UI/UX 想法。目的是生成 2-3 个可交互的方案，让用户并排对比视觉方向，而非产出可交付的代码。

当用户说以下内容时加载此 skill："sketch this screen"、"show me what X could look like"、"compare layout A vs B"、"give me 2-3 takes on this UI"、"let me see some variants"、"mockup this before I build"。

不适用场景

用户需要生产级组件——使用 claude-design 或正式构建

用户需要精良的一次性 HTML 产物（落地页、幻灯片）——使用 claude-design

用户需要图表——使用 excalidraw、architecture-diagram

设计已确定——直接构建即可

如果用户安装了完整的 GSD 系统

如果 gsd-sketch 作为同级 skill 出现（通过 npx get-shit-done-cc --hermes 安装），优先使用 gsd-sketch 以获得完整工作流：持久化的 .planning/sketches/ 目录（含 MANIFEST）、前沿模式分析、跨历史草图的一致性审计，以及与 GSD 其余部分的集成。本 skill 是轻量级独立版本——无状态机制的一次性草图。

核心方法

intake  →  variants  →  head-to-head  →  pick winner (or iterate)

1. Intake（如果用户已提供足够信息则跳过）

在生成方案之前，获取三项信息——每次只问一个问题，不要一次全问：

感觉。 "这个应该给人什么感觉？形容词、情绪、氛围。"——"calm, editorial, like Linear" 比 "minimal" 更有参考价值。

参考。 "哪些 app、网站或产品接近你想象中的感觉？"——实际参考比抽象描述更有效。

核心操作。 "用户在这个页面上最重要的单一操作是什么？"——所有方案都应服务于此；否则只是装饰。

每次回答后简短复述，再问下一个问题。如果用户已一次性提供了全部三项，直接跳到方案生成。

2. 方案（2-3 个，不少于 1 个，极少超过 4 个）

一次性生成 2-3 个方案。每个方案是一个完整的独立 HTML 文件。不要描述方案——直接构建。目的是对比。

每个方案应采取不同的设计立场，而非不同的像素值。三种有效的方案维度：

密度： 紧凑 / 宽松 / 极密（选两个对比极端）

重点： 内容优先 / 操作优先 / 工具优先

美学： 编辑风格 / 实用主义 / 趣味性

布局： 单列 / 侧边栏 / 分屏

基调： 卡片式 / 纯内容 / 文档风格

选定一个维度并从中拉开差距。两个仅在强调色上不同的方案是无效的——用户无法区分。

方案命名： 描述立场，而非编号。

sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md

3. 制作真实的 HTML

每个方案是一个单一自包含的 HTML 文件：

内联 <style>——无需构建步骤，无外部 CSS

系统字体或通过 <link> 引入一个 Google Font

通过 CDN 使用 Tailwind（<script src="https://cdn.tailwindcss.com"></script>）可以

真实的虚假内容——实际句子、实际姓名，而非"Lorem ipsum"

可交互：链接可点击，悬停效果真实，至少一个状态转换（展开/收起、筛选、切换）。一个冻结的静态图比一个粗糙但有动效的方案更差。

在浏览器中打开验证。如果看起来有问题，在展示给用户之前修复。

使用 Hermes 的浏览器工具对方案进行视觉验证。 不要只写 HTML 然后寄希望于它能正常渲染；加载每个方案并查看：

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?")

browser_vision 返回页面实际内容的 AI 描述及截图路径——能捕获纯源码检查遗漏的布局问题（例如字体导入静默失败、flex 容器塌陷）。修复后重新导航，直到每个方案看起来正确为止。

快速启动用的默认 CSS reset + 系统字体栈：

4. 方案 README

每个方案的 README.md 回答以下内容：

5. 正面对比

所有方案构建完成后，以对比形式呈现。不要只是罗列——给出观点：

让用户选出胜出方案，或将两个方案合并为混合版，或要求新一轮迭代。

主题化（当项目有视觉标识时）

如果用户有现有主题（颜色、字体、token），将共享 token 放入 sketches/themes/tokens.css 并在每个方案中 @import。保持 token 精简：

不要对一次性草图过度 token 化——三种颜色加一种字体通常已足够。

交互基准

当用户能够完成以下操作时，草图的交互程度即为合格：

点击主要操作并看到可见的变化（状态变更、模态框、toast、导航模拟）

看到一个有意义的状态转换（筛选列表、切换模式、展开/收起面板）

悬停可识别的交互元素（按钮、行、标签页）

超过此程度是对一次性草图的过度工程化。低于此程度则只是截图。

前沿模式（决定下一步草图内容）

如果草图已存在且用户询问"接下来应该草图什么？"：

一致性缺口——来自不同草图的两个胜出方案做出了独立选择，尚未组合在一起

未草图的页面——被引用但从未探索过

状态覆盖——已草图了正常路径，但未覆盖空状态 / 加载中 / 错误 / 千条数据

响应式缺口——在某一视口下验证过；在移动端 / 超宽屏下是否成立？

交互模式——静态布局已存在；过渡动效、拖拽、滚动行为尚未探索

提出 2-4 个命名候选项，让用户选择。

输出

在仓库根目录创建 sketches/（如果用户使用 GSD 约定则为 .planning/sketches/）

每个方案一个子目录：NNN-stance-name/index.html + README.md

告知用户如何打开：macOS 上用 open sketches/001-calm-editorial/index.html，Linux 上用 xdg-open，Windows 上用 start

保持方案的一次性特性——如果你觉得有必要保留某个草图，应将其提升为真实项目代码，而非作为资产保管

单个方案的典型工具调用序列：

terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")

对每个方案重复上述步骤，然后呈现对比表格。

"Sketch — 一次性 HTML 原型：2-3 个设计方案对比"

Sketch

Skill 元数据

参考：完整 SKILL.md

Sketch

不适用场景

如果用户安装了完整的 GSD 系统

核心方法

1. Intake（如果用户已提供足够信息则跳过）

2. 方案（2-3 个，不少于 1 个，极少超过 4 个）

3. 制作真实的 HTML

4. 方案 README

5. 正面对比

主题化（当项目有视觉标识时）

交互基准

前沿模式（决定下一步草图内容）

输出

致谢

"Sketch — 一次性 HTML 原型：2-3 个设计方案对比"

Sketch#

Skill 元数据#

参考：完整 SKILL.md#

Sketch#

不适用场景#

如果用户安装了完整的 GSD 系统#

核心方法#

1. Intake（如果用户已提供足够信息则跳过）#

2. 方案（2-3 个，不少于 1 个，极少超过 4 个）#

3. 制作真实的 HTML#

4. 方案 README#

5. 正面对比#

主题化（当项目有视觉标识时）#

交互基准#

前沿模式（决定下一步草图内容）#

输出#

致谢#

Sketch

Skill 元数据

参考：完整 SKILL.md

Sketch

不适用场景

如果用户安装了完整的 GSD 系统

核心方法

1. Intake（如果用户已提供足够信息则跳过）

2. 方案（2-3 个，不少于 1 个，极少超过 4 个）

3. 制作真实的 HTML

4. 方案 README

5. 正面对比

主题化（当项目有视觉标识时）

交互基准

前沿模式（决定下一步草图内容）

输出

致谢