NanoSkill
提交你的 Skill

HTML 模型草圖繪製器

作者NousResearch2KGitHub 星標GitHub

生成 2-3 個互動式 HTML 模型變體，以便在確定單一方法之前比較 UI/UX 設計方向。快速探索不同的視覺立場並收集回饋。

模型安全掃描通過

安裝指令

$ npx skills add https://github.com/NousResearch/hermes-agent/tree/main/skills/creative/sketch

關於

HTML 模型草圖繪製器是一項強大的技能，旨在幫助使用者透過一次性 HTML 模型快速探索和比較 UI/UX 設計方向。此工具不會只採用單一設計，而是生成 2-3 個互動式變體，允許並排比較不同的視覺立場。它非常適合早期設計探索，幫助您在投入大量開發之前視覺化概念並收集回饋。

這項技能專注於建立功能性、互動式 HTML 模型，超越靜態圖像。每個變體都是一個獨立的 HTML 檔案，包含內聯 CSS、系統字體和真實內容。關鍵是，這些模型包含基本的互動性，例如可點擊的連結、懸停狀態和至少一個狀態轉換，為使用者體驗提供更具體的手感。整合的瀏覽器工具允許視覺驗證，確保模型乾淨且無錯誤。

為了促進明智的決策，HTML 模型草圖繪製器提供了結構化的比較。每個變體都附帶一個詳細的 `README.md`，概述其設計原則、關鍵選擇、權衡和最適合的用例。生成後，一個比較表總結了各種設計維度上的差異，並附有主觀分析，以幫助您選擇獲勝者、組合元素或進一步迭代。

核心功能

它的強大之處

  • 生成多個設計變體

    同時產生 2-3 個不同的 HTML 模型變體，每個變體探索不同的設計立場（例如，密度、強調、美學、版面），以便並排比較。

  • 互動式 HTML 模型

    建立包含內聯 CSS、系統字體和真實假內容的獨立 HTML 檔案。模型是互動式的，允許點擊連結、懸停和至少一個狀態轉換。

  • 使用瀏覽器工具進行視覺驗證

    利用整合的瀏覽器導航和視覺工具，視覺化檢查和驗證每個 HTML 模型，確保版面乾淨、易讀且在呈現前沒有錯誤。

  • 結構化變體文件

    每個 HTML 模型變體都包含一個 `README.md`，詳細說明其設計立場、關鍵選擇（版面、排版、顏色、互動）、權衡和理想用例，以促進知情的比較。

  • 比較分析表

    以比較表的形式呈現所有生成的 HTML 模型變體，突出顯示密度、主要動作可見性、可掃描性和整體感覺等關鍵維度上的差異，並附有主觀總結。

使用場景

什麼時候適合使用

  • 探索 UI/UX 設計方向

    快速生成和比較多個 HTML 模型變體，以探索不同的使用者介面和使用者體驗設計理念，而無需投入大量的開發時間。

  • 收集視覺概念的回饋

    向利害關係人或使用者展示互動式 HTML 模型，以收集對各種視覺方向的早期回饋，幫助完善概念並做出明智的設計決策。

  • 新功能的快速原型製作

    建立一次性 HTML 模型，以快速原型製作新功能或畫面，重點關注核心功能和視覺流程，而不是可投入生產的程式碼。

SKILL.md

草圖

當使用者希望在確定設計方向之前，透過一次性 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 以獲得完整的工作流程：帶有 MANIFEST 的持久 .planning/sketches/、前沿模式分析、跨過去草圖的一致性審核，以及與 GSD 其餘部分的整合。此技能是輕量級的獨立版本 — 不帶狀態機制的單次草圖繪製。

核心方法

攝取 → 變體 → 正面比較 → 選擇獲勝者（或迭代）

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 字體
  • 透過 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="這個版面看起來乾淨易讀嗎？是否有任何可見的錯誤（文字重疊、未樣式化的元素、損壞的圖像）？")

browser_vision 返回頁面上實際內容的 AI 描述以及螢幕截圖路徑 — 捕獲純粹的原始碼檢查會遺漏的版面錯誤（例如，字體導入靜默失敗，flex 容器崩潰）。修復並重新導航，直到每個變體看起來都正確。

預設 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 回答：

## 變體：{立場名稱}

### 設計立場
一句話說明驅動此變體的原則。

### 關鍵選擇
- 版面：...
- 排版：...
- 顏色：...
- 互動：...

### 權衡
- 強項：...
- 弱項：...

### 最適合
- 此變體實際服務的使用者類型或用例

5. 正面比較

所有變體建構完成後，將它們作為比較呈現。不要只是列出 — 提出意見：

## 首頁的三種呈現方式

| 維度 | 平靜編輯風格 | 實用密集型 | 俏皮分割型 |
|-----------|----------------|-------------------|---------------|
| 密度 | 低 | 高 | 中 |
| 主要動作可見性 | 低 | 高 | 中 |
| 可掃描性 | 高 | 中 | 低 |
| 感覺 | 平靜、值得信賴 | 銳利、工具感 | 吸引人、充滿活力 |

**我的看法：** 實用密集型適合進階使用者，平靜編輯風格適合內容導向的受眾。俏皮分割型最弱 — 試圖兩者兼顧卻兩者皆不成功。

讓使用者選擇獲勝者，或將兩者組合成混合型，或要求進行下一輪。

主題化（當專案具有視覺識別時）

如果使用者有現有的主題（顏色、字體、標記），請將共享標記放在 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_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="這看起來怎麼樣？有沒有明顯的版面問題？")

對每個變體重複此操作，然後呈現比較表。

歸屬

改編自 GSD (Get Shit Done) 專案的 /gsd-sketch 工作流程 — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done)。完整的 GSD 系統提供持久的草圖狀態、主題/變體模式參考和一致性審核工作流程；透過 npx get-shit-done-cc --hermes --global 安裝。

常見問題