getdesign

getdesign

コーディングエージェント自身のツールを使って、あらゆる公開 URL を基にした、根拠のある本番品質の design.md を生成します。このスキルは、ホスト型の getdesign.app エージェントを持ち運び可能にしたもので、同じ 9 セクションの出力を、サンドボックスなしで実現します。

使用するタイミング

ユーザーが次のような依頼をしたときに有効にします。

• URL を貼り付け、「デザインシステム」「デザイン仕様」「スタイルガイド」、design.md、またはブランドトークンを求めている。
• 「このサイトのような見た目にして」「 のデザインをクローンして」「 の配色／タイポグラフィを抽出して」と依頼している。
• 公開中のサイトのビジュアルデザインをリバースエンジニアリングしたり、ドキュメント化したりするよう求めている。

次の用途ではこのスキルを使用しないでください。URL から実行可能なコードを生成する、Figma／Sketch 形式でエクスポートする、認証が必要なページを扱う、または localhost を扱う場合です。

出力仕様

成果物は design.md と、ドキュメント内で参照する実際にキャプチャしたスクリーンショットを格納する images/ ディレクトリです。共有時は、この 2 つを一緒にしてください。Markdown ファイル（既定のファイル名は design.md）には、次の 9 つの H2 セクションを、この順序で正確に含めます。

1. ビジュアルテーマと雰囲気
2. カラーパレットと役割
3. タイポグラフィのルール
4. コンポーネントのスタイル
5. レイアウトの原則
6. 奥行きと高さ
7. インタラクションとモーション
8. レスポンシブ動作
9. エージェント向けプロンプトガイド

セクションの完全なスキーマ、フィールド一覧、記入例は TEMPLATE.md にあります。最終ファイルを書く前に読んでください。

根拠に関するルール（必須）

具体的な値（16 進カラーコード、フォントファミリー、フォントサイズ、間隔の数値、角丸、シャドウ、ブレークポイント）はすべて、実際に取得した情報（CSS ルール、計算済みスタイル、<link> で読み込まれたスタイルシート、:root 変数、またはスクリーンショット上で確認できるピクセル）に基づいている必要があります。値の根拠を確認できない場合は、16 進カラーコードを捏造せず、「暖色系のニュートラルグレー」のように役割を定性的に説明してください。

パレットの値を創作しないでください。サイトで使われていない Tailwind クラスをでっち上げないでください。他のサイトの既定値をコピーしないでください。

ワークフロー

次の手順に従ってください。チェックリストを作業メモにコピーし、作業を進めながら項目にチェックを入れてください。

- [ ] 1. Validate URL
- [ ] 2. Fetch HTML + linked CSS
- [ ] 3. Capture at least one screenshot (hero viewport)
- [ ] 4. Extract tokens (colors, type, spacing, radii, shadows, breakpoints)
- [ ] 5. Draft DesignDoc (9 sections) grounded in tokens + screenshot
- [ ] 6. Render design.md from the draft
- [ ] 7. Save screenshots under images/, link them in design.md, and verify every image opens
- [ ] 8. Verify grounding + section order, then write the files

1. URL を検証する

URL が https:// で始まらない場合、プライベート IP／localhost の場合、またはブランド／製品のページではないことが明らかな場合は、理由を 1 行で説明して拒否します。

2. HTML とリンク先の CSS を取得する

組み込みの Web 取得ツール（WebFetch、web.run、fetch、シェル経由の curl など、利用できるもの）を使ってください。

• HTML を取得します。
• HTML から、すべての <link rel="stylesheet"> の href を解決（絶対 URL と相対 URL の両方）し、それぞれを取得します。
• @import url(...) のチェーンを 1 階層分たどります。
• フォントファミリーとウェイトを調べるため、@font-face ブロックをすべて取得します。
• 各スタイルシートの取得量は約 200 KB 以下にし、:root、CSS 変数、またはユーティリティクラスの宣言を含むファイルを優先します。
• 取得時は、ライトモードとダークモードの両方に対応しているかを必ず確認します。prefers-color-scheme、.dark、[data-theme]、テーマ切り替えコントロール、代替テーマのスタイルシート、<html>／<body> 上のサーバーレンダリングされたテーマクラスを調べます。
• サイトが両方のモードに対応している場合は、両方の根拠を収集し、どのトークンが共通で、どれがモード固有かをメモします。

取得した URL を正確に記録します。下書きの「Sources」セクションで参照するためです（内部用であり、最終 Markdown には含めません）。

3. ページのスクリーンショットを撮影する

エージェントのランタイムにブラウザツール（Playwright、Chrome DevTools、agent-browser、Antigravity ブラウザー、Codex web browser、screenshot ツールなど）がある場合は、必ず使用してください。URL を 1440×900 で開き、確認できるすべてのテーマモードのスクリーンショットを、ライトモード、ダークモードの順に撮影してください。可能であれば、ページ全体をスクロールしてつなぎ合わせてください。

• サイトにテーマ切り替え機能がある場合は、ブラウザーを使って両方のモードを撮影してください。
• 明示的な切り替え機能がない場合でも、可能であればブラウザーで prefers-color-scheme: light と prefers-color-scheme: dark をエミュレートして確認してください。
• ライトモードとダークモードのどちらで確認した内容か分かるよう、メモにモード名を記載してください。

実際に撮影したファイルを design.md と同じ場所にある images/ に保存し、hero-light.png、hero-dark.png、full-page.png など、内容が分かる名前を付けてください。ドキュメントの最初の H2 より前に、Markdown の画像参照を追加してください。これらは必須の成果物であり、一時的な分析用のファイルではありません。保存した各ファイルを開いて、読み込み画面やアクセス制限画面ではなく、ページが写っていることを確認してください。生成した画像、ファビコン、またはパレットの画像をサイトのスクリーンショットの代わりに使用してはいけません。

撮影できない、または失敗した場合は、そこで作業を止め、撮影できない理由を説明してください。ユーザーが明示的にテキストのみを選択した場合に限り、画像なしで続行できます。その場合は、出力の冒頭にテキストのみであることを明記してください。黙って要件を満たさないまま進めてはいけません。

4. トークンを抽出する

CSS を決定的に解析してください。参照元としては CSS 変数（--color-primary、--radius-lg など）と :root ブロックを優先してください。該当するものがない場合は、リテラル値の出現頻度を分析してください。

以下を含む内部の DesignTokens オブジェクトを作成してください。

• colors：primary[]、accent[]、neutral[]、semantic { success, warning, error, info }、surfaces[]、borders[]。
  • 各エントリーは { hex, role, source } とし、source には値が見つかった CSS セレクターまたは変数名を指定してください。
  • サイトが複数のテーマに対応している場合は、各トークンに light、dark、shared のいずれかを付記してください。
• typography：fontFamilies[]（display／body／mono）、scale[]（{ role, px, weightRange, lineHeight, letterSpacing }）。
• spacing：実際に使われている間隔の値（例：4、8、12、16、24、32、48、64 px）。
• radii：推定できる名前付きのスケール（sm、md、lg、pill）。
• shadows：確認した各 box-shadow と、推定した用途。
• borders：幅と色。
• breakpoints：@media クエリの最小幅。

CSS の値が出現する回数が少なく（2 回未満）、変数名もない場合は、パレットから除外し、個別の値として扱ってください。

5. デザインドキュメントの草案を作成する

トークン、スクリーンショット、および HTML 構造の確認結果を使って、9 つのセクションをそれぞれ草案として作成します。文章の長さよりも構成が重要です。各フィールドの要件については、TEMPLATE.md を確認してください。

セクションごとの主な注意事項：

• ビジュアルテーマ — 短い段落を 2～4 つ記述し、keyCharacteristics の箇条書きリスト（5～8 項目）を加えます。
• カラーパレットと役割 — 色ごとに表の行を作成します：| Hex | Role | Where seen |。プライマリ／アクセント／セマンティック／サーフェス／ボーダーに分類します。
• タイポグラフィルール — まず fontFamily の概要を 1 段落で記述し、次に階層テーブルを作成します：| Role | Font | Size | Weight | Line height | Letter spacing |。Display、H1、H2、H3、Body、Small、Mono の役割を最低限含めます。
• コンポーネントのスタイリング — ボタン（プライマリ／セカンダリ／ゴースト）、カード、入力欄、ナビゲーション、画像の処理方法、および実際に確認した特徴的なコンポーネントを 2～4 つ記述します。
• レイアウト原則 — スペーシングスケール、グリッド／最大幅、余白の方針、角丸スケールを記述します。
• 奥行きとエレベーション — シャドウ値とともに、名前付きのエレベーションレベルを記述し、方針を 1 文で説明します。
• インタラクションとモーション — 確認または推定したホバー状態、フォーカス状態、トランジションの時間とイージングを記述します。推定した内容には明示的に印を付けます。
• レスポンシブ動作 — @media クエリに基づくブレークポイントテーブル、タッチターゲットの最小サイズ、ナビゲーションの折りたたみ方、画像の動作を記述します。
• ライトモードとダークモードの両方がある場合は、ひとつのパレットにまとめず、該当するセクションで主なテーマの違いを説明します。
• エージェント向けプロンプトガイド — 色のクイックリファレンス（主要な hex 値のみ）、別の AI がこのスタイルを再現するために使えるプロンプト例を 3 つ、反復作業のヒントを 4～6 個記載します。

6. Markdown に書き出す

草案を 1 つの Markdown ドキュメントにまとめます。次の形式を使用してください。

• サイト名には H1 を使用します（# <Brand> Design System）。
• 上記の正確な順序で、9 つのセクションそれぞれに H2 を使用します。
• パレット、タイポグラフィ、ブレークポイントには GitHub Flavored Markdown のテーブルを使用します。
• コードフェンスは具体的な CSS／トークンの例にのみ使用し、文章を囲むためには使いません。

7. 検証してから書き込む

最終ファイルを書き込む前に、次のセルフチェックを実行します。

• 9 つの H2 セクション見出しがすべて揃っており、記載されているとおりの正確な順序で並んでいます。
• カラーパレットセクションのすべての hex コードが、CSS の出典とともに内部メモに記録されています。
• タイポグラフィに記載したフォントファミリーが、取得した CSS または @font-face ブロックに含まれています。
• ブレークポイントが実際の @media (min-width: …) クエリと一致しています。
• サイトがデュアルテーマをサポートしている、またはその可能性を示唆している場合、ライトモードとダークモードの両方を確認しています。
• 実際のスクリーンショットがドキュメントと同じ場所に保存され、相対パスの Markdown で参照されており、参照先のファイルがすべて開けます。明示的に選択され、テキストのみと明記された実行は例外です。
• 「TBD」、「(example)」、「Lorem ipsum」などのプレースホルダーテキストがありません。

チェックに失敗した場合は、修正してから書き込みます。その後、1 段落の要約と絶対ファイルパスを報告します。

機能が利用できない場合の対応

利用できないツール	代替対応
ブラウザー／スクリーンショット機能がない	停止して、キャプチャ機能が利用できないことを報告します。CSS のみの出力が許可されるのは、ユーザーがテキストのみを明示的に選択した後に限ります。その制限をドキュメントに明記してください。
取得がブロックされる（403／Cloudflare）	エラーを報告し、代替 URL としてサイトの / と /about を試します。それでも失敗した場合は停止し、エラーをユーザーに伝えます。推測は禁止です。
CSS-in-JS のみで、スタイルシートがない	インラインの <style> タグを解析します。それでも空の場合は、スクリーンショットと HTML のクラス名を使って、目に見える情報のみを推測します。この制限を design.md の冒頭に記載してください。

アンチパターン

• トークンを「美しく整える」ために、2回目の LLM 処理を実行しないでください。文章表現より決定性を優先してください。
• 9 つのセクションの順序を入れ替えたり、統合したり、分割したりしないでください。
• 最終成果物として JSON、YAML、Zod スキーマを出力しないでください。ユーザーが求めているのは Markdown です。
• npm パッケージをインストールしたり、サンドボックスを起動したりしないでください。このスキルは意図的にインフラを必要としません。
• @import を介した読み込みは 1 回までにしてください。コンテキストウィンドウには限りがあります。

参照ファイル

• TEMPLATE.md — 9 つのセクションそれぞれのフィールドごとのスキーマと、簡単な作成例。

クレジット

このスキルは、ホスト型エージェント（Web、API、CLI、SDK）である getdesign を参考にしています。ホスト型パイプラインのスクリーンショットと決定論的な抽出処理が出力に役立つ場合は、補完的な方法として curl "https://api.getdesign.app/?url=<encoded-url>" または npx @getdesign/cli <url> をユーザーに案内してください。