スケッチ
このスキルは、ユーザーがコミットする前にデザインの方向性を確認したい場合に使用します — UI/UXのアイデアを使い捨てのHTMLモックアップとして探索します。目的は、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の他の部分との統合。このスキルは軽量のスタンドアロンバージョンで、状態管理機構のない一回限りのスケッチです。
コアメソッド
intake → variants → head-to-head → pick winner (or iterate)
1. インテーク（ユーザーが既に十分な情報を提供している場合はスキップ）
バリエーションを生成する前に、3つのことを聞きます — 一度にすべてではなく、質問は一度に1つずつ：
- 感触。 「これはどのような感じにすべきですか？ 形容詞、感情、雰囲気。」 — 「落ち着いていて、編集風で、Linearのような」 と聞けば、「ミニマル」 よりも多くの情報が得られます。
- 参考。 「イメージしている感触を捉えているアプリ、サイト、製品はありますか？」 — 具体的な参考の方が抽象的な説明よりも優れています。
- コアアクション。 「ユーザーがこの画面で行う最も重要なことは何ですか？」 — バリエーションはすべてこれをうまく提供するべきであり、そうでなければ単なる装飾です。
各回答を次の質問の前に簡潔に反映させます。ユーザーが既に3つすべてを前もって提供している場合は、バリエーションに直接進みます。
2. バリエーション（2〜3、絶対に1つではなく、まれに4つ以上）
2〜3のバリエーション を一度に生成します。各バリエーションは完全で独立したHTMLファイルです。バリエーションを説明するのではなく、構築してください。ポイントは比較です。
各バリエーションは、異なるピクセル値ではなく、異なるデザインスタンス を取るべきです。良いバリエーションの軸を3つ挙げます：
- 密度: コンパクト / ゆったり / 超高密度（対照的な2極を選ぶ）
- 強調: コンテンツ重視 / アクション重視 / ツール重視
- 美的感覚: 編集風 / 実用的 / 遊び心
- レイアウト: 1カラム / サイドバー / 分割ペイン
- 基盤: カードベース / むき出しのコンテンツ / ドキュメントスタイル
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>経由の1つのGoogle Font - CDN経由のTailwind（
<script src="https://cdn.tailwindcss.com"></script>）は使用可能 - リアルなフェイクコンテンツ — 実際の文章、実際の名前、「Lorem ipsum」ではない
- インタラクティブ: リンクはクリック可能、ホバーは本物、少なくとも1つの状態遷移（開閉、フィルター、トグル）。静的な画像は、雑なアニメーションよりも悪いプロトタイプです。
ブラウザで開きます。壊れているように見える場合は、ユーザーに見せる前に修正してください。
バリエーションを視覚的に検証 — 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説明とスクリーンショットのパスを返します — 純粋なソース検査では見逃されるレイアウトバグ（例：サイレントに失敗したフォントインポート、折りたたまれたフレックスコンテナ）を捕捉します。各バリエーションが正しく見えるまで修正して再ナビゲートします。
デフォルトの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つの勝者バリアントが、まだ組み合わされていない独立した選択を行った
- スケッチされていない画面 — 参照されたが探索されていない
- 状態カバレッジ — 正常系はスケッチされたが、空 / ローディング / エラー / 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_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")
各バリアントに対して繰り返し、比較表を提示します。
帰属
GSD（Get Shit Done）プロジェクトの /gsd-sketch ワークフローから改変 — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done)。完全なGSDシステムは、永続的なスケッチ状態、テーマ/バリアントパターン参照、一貫性監査ワークフローを提供します； npx get-shit-done-cc --hermes --global でインストールします。