sketch

Sketch

当用户想在做出决定前先看看某个设计方向，以临时 HTML 模型探索 UI/UX 创意时，使用此技能。目标是生成 2-3 个可交互的变体，让用户并排比较不同的视觉方向，而不是产出可用于发布的代码。

当用户说“草拟一下这个屏幕”“让我看看 X 可以是什么样”“比较一下布局 A 和布局 B”“给我 2-3 种这个 UI 的方案”“让我看看几个变体”“我动手构建前先做个模型”之类的话时，加载此技能。

何时不使用此技能

• 用户需要生产级组件——使用 claude-design 或按正式方式构建
• 用户需要精致的一次性 HTML 成品（着陆页、演示文稿）——使用 claude-design
• 用户需要图表——使用 excalidraw、architecture-diagram
• 设计方向已经确定——直接构建

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

如果 gsd-sketch 作为同级技能出现（通过 npx get-shit-done-cc --hermes 安装），可以使用 gsd-sketch 来采用更完整的工作流：将内容持久化到 .planning/sketches/，包含 MANIFEST、前沿模式分析、对过往草图的一致性审计，以及与 GSD 其余部分集成。此技能是轻量的独立版本——用于一次性草拟，不涉及状态管理机制。

注意： 上游 GSD 项目（gsd-build/get-shit-done）已在 GitHub 上归档／停止维护。npm 包（get-shit-done-cc）仍可安装，但应将其视为已归档的社区项目——此独立的 sketch 技能是受维护的方案，无需额外依赖。

核心方法

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

1. 收集信息（如果用户已经提供了足够信息，则跳过）

生成变体之前，先了解三件事——每次只问一个问题，不要一次全问完：

1. 感觉。“你希望它给人什么感觉？可以用形容词、情绪或氛围来描述。”—— “平静、像编辑设计、像 Linear” 比 “极简” 更能说明问题。
2. 参考。“有哪些应用、网站或产品，符合你设想的感觉？”——具体参考胜过抽象描述。
3. 核心操作。“用户在这个屏幕上要执行的最重要操作是什么？”——所有变体都应很好地服务于这一操作；否则它们就只是装饰。

在提出下一个问题前，简短复述用户的回答。如果用户一开始就提供了这三项信息，直接进入变体设计。

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 的 browser_exec 从视觉上验证各个变体。 不要只写 HTML，然后希望它能正常渲染；加载每个变体并检查效果：

browser_exec(code='''
# Checking sketch 001 renders cleanly
new_tab("file:///absolute/path/to/sketches/001-calm-editorial/index.html")
wait_for_load()
capture_screenshot()
''')

查看附带的截图并思考：这个布局是否简洁易读？有没有明显的问题（文本重叠、未设置样式的元素、图片损坏）？（非视觉模型：使用 vision_analyze 分析打印出的路径，并提出这个问题。）这能发现仅检查源代码无法发现的布局问题（例如字体导入无声失败、flex 容器塌陷）。修复后重新加载（使用同一 URL 调用 goto_url(...)），直到每个变体看起来都正常。

快速起步时，使用默认 CSS 重置和系统字体栈：

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. 变体 README

每个变体的 README.md 应回答：

## Variant: {stance name}

### Design stance
One sentence on the principle driving this variant.

### Key choices
- Layout: ...
- Typography: ...
- Color: ...
- Interaction: ...

### Trade-offs
- Strong at: ...
- Weak at: ...

### Best for
- The kind of user or use case this variant actually serves

5. 正面对比

构建完所有变体后，将它们作为对比方案展示。不要只是罗列——要给出鲜明的观点：

## Three takes on the home screen

| Dimension | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Density   | Low            | High              | Medium        |
| Primary action visibility | Low | High | Medium |
| Scan-ability | High | Medium | Low |
| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |

**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.

让用户选出胜出方案、将两个方案结合成混合方案，或要求再来一轮。

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

如果用户已有主题（颜色、字体、设计令牌），将共享令牌放在 sketches/themes/tokens.css 中，并在每个变体中使用 @import 引入。令牌应尽量精简：

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

不要给一次性草图过度抽象令牌——通常三种颜色和一种字体就够了。

交互标准

当用户可以进行以下操作时，草图的交互性就足够了：

1. 点击主要操作，并看到明显的效果（状态变化、模态框、提示消息、模拟导航）
2. 看到一种有意义的状态转换（筛选列表、切换模式、打开/关闭面板）
3. 将明显可交互的元素悬停（按钮、行、标签页）

再多就是对一次性草图过度设计。再少就只是一张截图。

前沿模式（选择接下来要绘制的草图）

如果已有草图，而用户问“接下来该画什么草图？”，请考虑：

• 一致性缺口——来自不同草图的两个胜出方案各自做出了独立选择，但尚未组合在一起
• 尚未绘制的屏幕——被提及过，但从未探索
• 状态覆盖——已绘制正常流程，但尚未覆盖空状态、加载状态、错误状态或 1000 项数据的情况
• 响应式缺口——只在一个视口验证过；在移动设备或超宽屏上是否仍然适用？
• 交互模式——已有静态布局，但尚未设计状态转换、拖动和滚动行为

提出 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_exec(code='new_tab("file:///abs/path/sketches/001-calm-editorial/index.html"); wait_for_load(); capture_screenshot()')
# then check the screenshot: any obvious layout issues?

对每个变体重复此过程，然后展示对比表。

归属说明

改编自 GSD（Get Shit Done）项目的 /gsd-sketch 工作流——MIT © 2025 Lex Christopherson（gsd-build/get-shit-done）。上游 GSD 仓库目前已在 GitHub 上归档/停止维护；get-shit-done-cc npm 包仍可安装（npx get-shit-done-cc --hermes --global），并提供持久化草图状态、主题/变体模式参考和一致性审计工作流，但请将其视为已归档的社区项目。