Back to Details

sketch

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sketch

Sketch

Use this skill when the user wants to see a design direction before committing to one — exploring a UI/UX idea as disposable HTML mockups. The point is to generate 2-3 interactive variants so the user can compare visual directions side-by-side, not to produce shippable code.
Load this when the user says things like "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".
当用户希望在确定最终方案前查看设计方向时使用此技能——将UI/UX想法转化为可丢弃的HTML原型。核心是生成2-3个可交互的变体，方便用户直观对比不同视觉方向，而非产出可上线的代码。
当用户说出以下类似需求时启用此技能：“快速制作这个页面的原型”、“展示X可能的样子”、“对比布局A和B”、“给我2-3种这个UI的方案”、“让我看看一些变体”、“在开发前先做个原型”。

When NOT to use this

不适用场景

  • User wants a production component — use 
    claude-design
    or build it properly
  • User wants a polished one-off HTML artifact (landing page, deck) — 
    claude-design
  • User wants a diagram — 
    excalidraw
    , 
    architecture-diagram
  • The design is already locked — just build it
  • 用户需要生产级组件——使用
    claude-design
    或按标准流程开发
  • 用户需要精致的一次性HTML制品（着陆页、演示文档）——使用
    claude-design
  • 用户需要图表——使用
    excalidraw
    、
    architecture-diagram
  • 设计方案已确定——直接开发即可

If the user has the full GSD system installed

若用户已安装完整GSD系统

If 
gsd-sketch
shows up as a sibling skill (installed via 
npx get-shit-done-cc --hermes
), prefer 
gsd-sketch
 for the full workflow: persistent 
.planning/sketches/
with MANIFEST, frontier mode analysis, consistency audits across past sketches, and integration with the rest of GSD. This skill is the lightweight standalone version — one-off sketching without the state machinery.
如果
gsd-sketch
作为同级技能存在（通过
npx get-shit-done-cc --hermes
安装），优先使用**
gsd-sketch
**完成全流程：它支持在
.planning/sketches/
目录下持久化存储并生成MANIFEST文件、前沿模式分析、跨历史原型的一致性审计，以及与GSD其他模块集成。本技能是轻量独立版本——无需状态机制的一次性原型制作工具。

Core method

核心流程

intake  →  variants  →  head-to-head  →  pick winner (or iterate)
需求收集  →  生成变体  →  横向对比  →  选定方案（或迭代）

1. Intake (skip if the user already gave you enough)

1. 需求收集（若用户已提供足够信息可跳过）

Before generating variants, get three things — one question at a time, not all at once:
  1. Feel. "What should this feel like? Adjectives, emotions, a vibe." — "calm, editorial, like Linear" tells you more than "minimal".
  2. References. "What apps, sites, or products capture the feel you're imagining?" — actual references beat abstract descriptions.
  3. Core action. "What's the single most important thing a user does on this screen?" — the variants should all serve this well; if they don't, they're just decoration.
Reflect each answer briefly before the next question. If the user already gave you all three upfront, skip straight to variants.
生成变体前，需依次获取以下三个信息，每次只提一个问题：
  1. 风格感受：“这个设计应该给人什么感觉？请用形容词、情绪或氛围描述。”——例如“平静、编辑风格、类似Linear”比“极简”更具参考性。
  2. 参考案例：“哪些应用、网站或产品符合你想象中的风格？”——实际案例比抽象描述更有效。
  3. 核心操作：“用户在这个页面上最重要的操作是什么？”——所有变体都应优先服务于该操作；否则只是无意义的装饰。
每个问题得到回答后简要确认，再提出下一个问题。若用户已一次性提供全部三个信息，可直接进入变体生成环节。

2. Variants (2-3, never 1, rarely 4+)

2. 生成变体（2-3个，绝不只1个，很少超过4个）

Produce 2-3 variants in one go. Each variant is a complete, standalone HTML file. Don't describe variants — build them. The point is comparison.
Each variant should take a different design stance, not different pixel values. Three good variant axes:
  • Density: compact / airy / ultra-dense (pick two contrasting poles)
  • Emphasis: content-first / action-first / tool-first
  • Aesthetic: editorial / utilitarian / playful
  • Layout: single-column / sidebar / split-pane
  • Grounding: card-based / bare-content / document-style
Pick one axis and pull apart from it. Two variants that differ only in accent color are wasted effort — the user can't distinguish them.
Variant naming: describe the stance, not the number.
sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md
一次性生成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. Make them real HTML

3. 制作真实HTML文件

Each variant is a single self-contained HTML file:
  • Inline 
    <style>
    — no build step, no external CSS
  • System fonts or one Google Font via 
    <link>
  • Tailwind via CDN (
    <script src="https://cdn.tailwindcss.com"></script>
    ) is fine
  • Realistic fake content — actual sentences, actual names, not "Lorem ipsum"
  • Interactive: links clickable, hovers real, at least one state transition (open/close, filter, toggle). A frozen static image is a worse spike than a sloppy animated one.
Open it in a browser. If it looks broken, fix it before showing the user.
Verify variants visually — use Hermes' browser tools. Don't just write HTML and hope it renders; load each variant and look at it:
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
returns an AI description of what's actually on the page plus a screenshot path — catches layout bugs that pure source inspection misses (e.g. a font import that silently failed, a flex container that collapsed). Fix and re-navigate until each variant looks right.
Default CSS reset + system font stack for fast starts:
html
<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>
每个变体都是独立自包含的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重置+系统字体栈：
html
<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. Variant README

4. 变体README文档

Each variant's 
README.md
answers:
markdown
undefined
每个变体的
README.md
需包含以下内容：
markdown
undefined

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
undefined
  • 此变体最适合的用户群体或使用场景
undefined

5. Head-to-head

5. 横向对比

After all variants are built, present them as a comparison. Don't just list — opinionate:
markdown
undefined
所有变体制作完成后，以对比形式呈现给用户。不要仅罗列——给出专业建议：
markdown
undefined

Three takes on the home screen

首页的三种设计方案

DimensionCalm editorialUtilitarian densePlayful split
DensityLowHighMedium
Primary action visibilityLowHighMedium
Scan-abilityHighMediumLow
FeelCalm, trustedSharp, tool-likeInviting, 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.

Let the user pick a winner, or combine two into a hybrid, or ask for another round.
维度平静编辑风实用紧凑风趣味分栏风
密度低高中等
核心操作可见性低高中等
易读性高中等低
整体感受平静、可信干练、工具化亲切、有活力
专业建议：实用紧凑风适合高级用户，平静编辑风适合内容导向型受众。趣味分栏风表现最弱——试图兼顾两者却未能明确立场。

让用户选定最优方案，或结合两个变体生成混合方案，或要求进行下一轮迭代。

Theming (when the project has a visual identity)

主题适配（当项目已有视觉标识时）

If the user has an existing theme (colors, fonts, tokens), put shared tokens in 
sketches/themes/tokens.css
and 
@import
them in each variant. Keep tokens minimal:
css
/* 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;
}
Don't over-tokenize a throwaway sketch — three colors and one font is usually enough.
若用户已有现成主题（色彩、字体、设计变量），可将共享变量存入
sketches/themes/tokens.css
，并在每个变体中通过
@import
引入。变量需保持精简：
css
/* 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;
}
不要为一次性原型过度设置变量——通常三种颜色+一种字体就足够。

Interactivity bar

交互性标准

A sketch is interactive enough when the user can:
  1. Click a primary action and something visible happens (state change, modal, toast, navigation feint)
  2. See one meaningful state transition (filter a list, toggle a mode, open/close a panel)
  3. Hover recognizable affordances (buttons, rows, tabs)
More than that is over-engineering a throwaway. Less than that is a screenshot.
一个原型的交互性达标需满足：
  1. 点击核心操作后有可见反馈（状态变化、弹窗、提示、模拟导航）
  2. 包含一个有意义的状态切换（筛选列表、切换模式、展开/收起面板）
  3. 可识别元素支持悬停（按钮、列表项、标签页）
超出以上标准属于过度设计，低于则只是静态截图。

Frontier mode (picking what to sketch next)

前沿模式（确定下一个原型方向）

If sketches already exist and the user says "what should I sketch next?":
  • Consistency gaps — two winning variants from different sketches made independent choices that haven't been composed together yet
  • Unsketched screens — referenced but never explored
  • State coverage — happy path sketched, but not empty / loading / error / 1000-items
  • Responsive gaps — validated at one viewport; does it hold at mobile / ultrawide?
  • Interaction patterns — static layouts exist; transitions, drag, scroll behavior don't
Propose 2-4 named candidates. Let the user pick.
若已有原型，用户询问“接下来应该制作什么原型？”时，可从以下方向入手：
  • 一致性缺口——不同原型中的最优方案存在未整合的独立设计选择
  • 未制作的页面——已提及但未探索的页面
  • 状态覆盖——已制作正常流程原型，但未覆盖空状态/加载中/错误/大量数据状态
  • 响应式缺口——已在一种视口尺寸下验证，但未适配移动端/超宽屏
  • 交互模式——已有静态布局，但未实现过渡动画、拖拽、滚动行为
提出2-4个命名候选方案，让用户选择。

Output

输出规范

  • Create 
    sketches/
    (or 
    .planning/sketches/
    if the user is using GSD conventions) in the repo root
  • One subdir per variant: 
    NNN-stance-name/index.html
    + 
    README.md
  • Tell the user how to open them: 
    open sketches/001-calm-editorial/index.html
    on macOS, 
    xdg-open
    on Linux, 
    start
    on Windows
  • Keep variants disposable — a sketch that you felt the need to preserve should be promoted into real project code, not curated as an asset
Typical tool sequence for one variant:
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?")
Repeat for each variant, then present the comparison table.
  • 在仓库根目录创建
    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?")
重复以上流程制作每个变体，然后呈现对比表格。

Attribution

来源说明

Adapted from the GSD (Get Shit Done) project's 
/gsd-sketch
workflow — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). The full GSD system ships persistent sketch state, theme/variant pattern references, and consistency-audit workflows; install with 
npx get-shit-done-cc --hermes --global
.
改编自GSD（Get Shit Done）项目的
/gsd-sketch
工作流——MIT协议 © 2025 Lex Christopherson（gsd-build/get-shit-done）。完整GSD系统支持原型状态持久化、主题/变体模式参考及一致性审计工作流；可通过
npx get-shit-done-cc --hermes --global
安装。