mcpField
S
sketch

sketch

github.com/nousresearchデザイン・UI258.9k404 回インストール今日更新
リポジトリ

sketch について

使い捨てのインタラクティブな HTML モックアップで UI/UX の方向性を探る軽量スキルです。実装前に画面案を比較するチーム向けに、異なる複数案の作成から比較レビューまでを支援します。

主な機能

  1. 01異なる案を 2~3 個生成
  2. 02独立したインタラクティブ HTML を作成
  3. 03複数案を並べて比較
  4. 04ブラウザーで表示を確認
  5. 05別画面や状態の検討

活用シーン

  1. 01画面構築前のレイアウト比較
  2. 02UI の異なるビジュアルスタイルの検討
  3. 03レスポンシブや操作状態の不足を発見

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nousresearch/hermes-agent --skill sketch

インストール後、Claude Code で/sketchを入力して読み込まれたか確認します。

詳細

スケッチ

ユーザーが方向性を決める前にデザインの方向性を見たい場合に、このスキルを使います。使い捨ての HTML モックアップで UI/UX のアイデアを試します。目的は、ユーザーが視覚的な方向性を並べて比較できるよう、インタラクティブなバリエーションを 2~3 種類生成することであり、そのままリリースできるコードを作ることではありません。

「この画面をスケッチして」「X がどんな感じになるか見せて」「レイアウト A と B を比較して」「この UI の案を 2~3 種類出して」「いくつかのバリエーションを見せて」「作り始める前にモックアップを作って」などと言われた場合に読み込みます。

使用しない場合

  • ユーザーが本番用のコンポーネントを求めている場合 — claude-design を使うか、適切に実装してください
  • ユーザーが洗練された単発の HTML 成果物(ランディングページ、スライド資料)を求めている場合 — claude-design
  • ユーザーが図を求めている場合 — excalidraw、architecture-diagram
  • デザインがすでに確定している場合 — そのまま実装してください

ユーザーが GSD システム一式をインストールしている場合

gsd-sketch が兄弟スキルとして表示される場合(npx get-shit-done-cc --hermes でインストール済み)、より充実したワークフローには gsd-sketch を使えます。MANIFEST を備えた永続的な .planning/sketches/、フロンティアモード分析、過去のスケッチとの整合性監査、GSD の他の機能との連携を利用できます。このスキルは軽量な単独版で、状態管理の仕組みを使わず、その場限りのスケッチを行います。

注: 上流の GSD プロジェクト(gsd-build/get-shit-done)は GitHub でアーカイブ済み/メンテナンス終了です。npm パッケージ(get-shit-done-cc)は引き続きインストールできますが、アーカイブ済みのコミュニティプロジェクトとして扱ってください。メンテナンスされているのはこの単独版の sketch スキルで、追加のものは必要ありません。

基本的な方法

intake  →  variants  →  head-to-head  →  pick winner (or iterate)
1. ヒアリング(ユーザーからすでに十分な情報が得られている場合は省略)

バリエーションを生成する前に、次の 3 点を確認します。質問は一度に 1 つずつ行い、まとめて尋ねないでください。

  1. 雰囲気。 「どんな印象にしたいですか? 形容詞や感情、雰囲気を教えてください。」— *「穏やかで、エディトリアルな感じで、Linear のように」は、「ミニマル」*より多くの情報を伝えてくれます。
  2. 参考例。 「イメージしている雰囲気に近いアプリ、サイト、製品はありますか?」— 抽象的な説明より、実際の参考例のほうが役立ちます。
  3. 主要な操作。 「ユーザーがこの画面で行う最も重要な操作は何ですか?」— すべてのバリエーションがその操作をうまく支える必要があります。そうでなければ、単なる飾りにすぎません。

次の質問に進む前に、それぞれの回答を簡潔に言い換えて確認します。ユーザーが最初から 3 点すべてを伝えている場合は、そのままバリエーションの作成に進みます。

2. バリエーション(2~3 種類。1 種類は不可、4 種類以上はまれ)

一度に2~3 種類のバリエーションを作成します。それぞれ、単体で完結する HTML ファイルにしてください。バリエーションを説明するのではなく、実際に作成してください。目的は比較です。

各バリエーションでは、ピクセル値を変えるのではなく、異なるデザイン方針を採用します。バリエーションの軸として適しているものは次のとおりです。

  • 密度: コンパクト/ゆったり/超高密度(対照的な両極を 2 つ選ぶ)
  • 強調点: コンテンツ優先/操作優先/ツール優先
  • 美的方向性: エディトリアル/実用的/遊び心のある
  • レイアウト: 単一カラム/サイドバー/分割ペイン
  • 構成: カード型/コンテンツをそのまま表示/ドキュメント風

軸を 1 つ選び、その両極に分かれるようにします。アクセントカラーだけが異なる 2 つのバリエーションでは、ユーザーが違いを見分けられず、労力が無駄になります。

バリエーションの命名: 番号ではなく、デザイン方針を表す名前を付けてください。

sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md
3. 本物の HTML を作成する

各バリアントは、単独で動作する 1 つの HTML ファイルです。

  • インラインの <style> を使用します。ビルド手順や外部 CSS は不要です
  • システムフォント、または <link> で読み込む Google Font を 1 つ使用します
  • CDN 経由の Tailwind(<script src="https://cdn.tailwindcss.com"></script>)は使用できます
  • 現実味のある仮のコンテンツを使います。実際の文章や名前を使用し、「Lorem ipsum」は使いません
  • インタラクティブにします。リンクをクリックでき、ホバーが機能し、少なくとも 1 つの状態遷移(開閉、フィルター、切り替え)を用意します。静止した画像よりも、粗削りでもアニメーションする試作のほうが優れています

ブラウザーで開きます。表示が崩れていたら、ユーザーに見せる前に修正してください。

バリアントを視覚的に検証します。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 に渡してください)。ソースコードだけの確認では見つからないレイアウト上の不具合(読み込みに失敗したフォント、つぶれたフレックスコンテナーなど)も検出できます。各バリアントが適切に表示されるまで修正して再読み込みしてください(同じ 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.

ユーザーに最良の案を選んでもらうか、2 つを組み合わせてハイブリッドにするか、もう一度作成するかを尋ねます。

テーマ設定(プロジェクトにビジュアルアイデンティティがある場合)

ユーザーが既存のテーマ(色、フォント、トークン)を使っている場合は、共通トークンを 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;
}

使い捨てのスケッチでトークンを細分化しすぎないでください。通常は 3 色と 1 つのフォントで十分です。

インタラクションの基準

ユーザーが次のことをできれば、スケッチとして十分にインタラクティブです。

  1. 主要なアクションをクリックすると、目に見える変化(状態変更、モーダル、トースト、画面遷移の演出)が起こる
  2. 意味のある状態遷移を 1 つ確認できる(リストのフィルター、モードの切り替え、パネルの開閉)
  3. 操作できる要素のホバー状態を確認できる(ボタン、行、タブ)

これ以上は使い捨てのスケッチとしては過剰な作り込みです。これ未満ではスクリーンショットにすぎません。

フロンティアモード(次にスケッチする対象を選ぶ)

すでにスケッチがあり、ユーザーが「次は何をスケッチすればよいですか?」と尋ねた場合:

  • 一貫性のギャップ — 別々のスケッチで選ばれた 2 つのバリアントが、それぞれ独立した判断をしており、まだ組み合わせていないもの
  • 未スケッチの画面 — 参照されているものの、まだ検討されていない画面
  • 状態のカバレッジ — 正常系はスケッチされているが、空、読み込み中、エラー、1000 件の項目といった状態は未対応
  • レスポンシブ対応のギャップ — 1 つのビューポートでしか検証していない場合、モバイルやウルトラワイドでも適切に表示されるか
  • インタラクションパターン — 静的なレイアウトはあるが、状態遷移、ドラッグ、スクロール動作が未対応

名前を付けた候補を 2~4 件提案し、ユーザーに選んでもらいます。

出力

  • リポジトリのルートに sketches/ を作成します(ユーザーが GSD の規約を使用している場合は .planning/sketches/)
  • バリアントごとにサブディレクトリを 1 つ作成します:NNN-stance-name/index.html と README.md
  • 開き方をユーザーに伝えます:macOS では open sketches/001-calm-editorial/index.html、Linux では xdg-open、Windows では start
  • バリアントは使い捨てとして扱います。残しておきたいと思ったスケッチはアセットとして整理するのではなく、実際のプロジェクトコードに昇格させてください

1 つのバリアントを作成する場合の一般的なツールの実行順序:

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)で、永続的なスケッチ状態、テーマ/バリアントのパターン参照、一貫性監査のワークフローが含まれていますが、アーカイブ済みのコミュニティプロジェクトとして扱ってください。

コメント