Menú
対話または既存トークンファイル（W3C DTCG / CSS variables など）をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | generate |
| description | 対話または既存トークンファイル（W3C DTCG / CSS variables など）をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。 |
| argument-hint | ["プロダクトの説明やURL（省略可）"] |
AIが一貫したUIを生成するための DESIGN.md を、対話または既存トークンの取り込みから作成するスキル。
DESIGN.md は、AIエージェントがUIを生成・修正する際のビジュアル判断基準を定義するMarkdownファイルです。 このスキルは対話を通じてユーザーのデザイン意図を引き出し、必要に応じて既存のトークンファイルを取り込みながら DESIGN.md を生成します。
このスキルを実行する前に、以下のリソースを必ず読み込むこと：
../../DESIGN-MD-SPEC.md — フォーマット仕様（セクション構成、3層記述パターン、対応表フォーマット）resources/writing-guide.md — 良い記述と悪い記述の Before/Afterresources/examples/ — 完成例3パターン（saas-dashboard, creator-platform, minimal-zen）プロジェクトルートに DESIGN.md が既に存在するか確認する。
存在しない → Step 1 へ進む
存在する → 既存の DESIGN.md を Read で読み、以下の簡易診断を行う:
簡易診断（内部処理）:
generated 日付から3ヶ月以上経過している場合、全体的な見直しを推奨診断結果をユーザーに提示する: 「既存の DESIGN.md を診断しました:
更新しますか？ それとも新しく作り直しますか？」
ユーザーが渡したファイル、プロジェクト内のトークンファイル、既存CSSを確認し、「何を下敷きにできるか」を判断する。
重要:
構造ベースの判定ルール:
$value があれば token、$type があれば型として扱う。$type は親グループから継承される前提で解釈する:root やテーマスコープ内の --color-*, --space-*, --font-*, --radius-*, --shadow-* などをトークン候補として読む$value を持ちながら子token/groupも持つ場合は不正。ユーザーに「このファイルは token と group が混在しているため、そのままは読めない」と伝えるW3C DTCG JSON の最低限の解釈:
color → Color StrategyfontFamily, fontWeight, dimension（font size / line height を含む場合）→ Typographydimension（spacing / gap / inset 系）→ Spacing & Layoutdimension（radius / border-width / stroke 系）→ Effectsshadow → Effectsduration, cubicBezier → Motion & Transitionsdimension は汎用型なので、キー名と用途から spacing / radius / border / sizing を判定する候補が見つかったらユーザーに短く確認する: 「既存のトークンファイルが見つかりました。これは値の正として取り込みますか？ それとも参考情報として扱いますか？」
進め方の原則:
以下の情報を対話で引き出す。すべてを聞く必要はなく、ユーザーが提供できる情報に合わせて柔軟に進める。
必須で聞くこと：
任意で聞くこと（ユーザーが答えられれば）： 4. 「既存のデザインシステムやトークンファイルはありますか？（W3C DTCG JSON、CSS variables、tokens.json など）」 → Token References、具体値の取得 5. 「絶対に避けたい印象やスタイルはありますか？」 → Global Constraints、Creative North Star の "This does NOT mean" 6. 「対象プラットフォームは？（Web/Mobile/両方）」 → Frontmatter の platform 7. 「現在のUIやブランドで、変えたくない要素はありますか？」 → Global Constraints、Color Strategy の制約として反映 8. 「絶対に手を抜けない画面はどれですか？理由も教えてください」 → 品質の重点領域の特定、TL;DR の死守ライン、名前付きルールの粒度判断に使用
補助入力を活用する：
ヒアリングの心得：
ヒアリングで得た情報をもとに DESIGN.md を生成する。
ルールの検証可能性チェック（出力には露出しない）:
フォーマット:
../../DESIGN-MD-SPEC.md の構成に厳密に従うmode は主な入力源に合わせて選ぶ
conversationtokens-importhybrid3層記述パターンを守る:
トークン取り込み時の扱い:
token_source には実際の参照元パスを書く。複数ある場合は最も支配的なソースを書くか、Design Token References セクションで列挙するdimension は spacing / radius / border-width / sizing に分かれうるため、名称と利用文脈を確認してからマッピングするshadow / radius / border の判断基準が明示的に存在する場合は Effects セクションを生成する名前付きルール:
Creative North Star:
否定形の扱い:
❌ Don't: 影を使うな → ✅ 影を使わない → 代わりにサーフェス色差で階層を表現する言語:
具体値 vs 原則:
Effects に具体値必須コンテンツ特性に応じた判断基準:
感情を伴うインタラクションへの判断基準:
テンプレートバイアスの回避:
[SKIP] として省略可能DESIGN.md は「制約」ではなく「創造の方向性」:
❌ **自由領域:** ホバーエフェクトの演出は自由
✅ **自由領域:** ホバーエフェクトの演出。書斎で本を手に取る瞬間のように、静かだが確かな変化を
カラーコントラスト検証（必須）:
特殊コンポーネントへの対応:
When Principles Conflict の独自性:
生成した DESIGN.md をユーザーに提示する前に、以下の観点で内部チェックする。 問題があれば Step 2 に戻って修正する。チェック結果はユーザーに表示しない。
構造チェック:
mode と token_source が入力実態に合っているかEffects セクションがあるか品質チェック:
表現力チェック:
カラーコントラストチェック（必須）:
一貫性チェック:
曖昧性チェック:
生成した DESIGN.md をユーザーに提示する。
提示時のメッセージ：
DESIGN.md を生成しました。
**Creative North Star:** [メタファー名]
**セクション構成:**
- [含まれるセクションの一覧]
**特に確認してほしいポイント:**
- [Creative North Star のメタファーが意図に合っているか]
- [Color Palette の色が期待通りか]
- [Global Constraints に違和感がないか]
修正したい箇所があれば教えてください。
また、この DESIGN.md を使って実際にUIを1つ生成してみて、意図通りか確認しますか？
ユーザーから修正指示があった場合は、該当箇所を修正して Step 3（自己検証）→ Step 4（再提示）を繰り返す。
生成した DESIGN.md を使って、サンプルUIコンポーネント（例：ログインフォーム、カード一覧、ダッシュボードヘッダー等）を1つ生成する。
ユーザーのプロジェクトの技術スタックで生成する。不明な場合は HTML + Tailwind CSS で生成する。
ユーザーに「意図通りですか？」と確認し、必要に応じて DESIGN.md を修正する。
ユーザーの承認を得たら、プロジェクトルートに DESIGN.md として保存する。
必要であれば、DESIGN.md から W3C DTCG 形式の design-tokens.json を任意出力してよい。
ただし、これは外部ツールとの接続のための下支えであり、DESIGN.md の本文を置き換えるものではない。
W3C DTCG JSON を出力する場合の必須手順:
https://design-tokens.github.io/community-group/format/）を読むdesign-tokens.meta.md）または生成時の説明文に記録するdimension は spacing / radius / border-width / sizing を区別して出力し、用途が曖昧な値はユーザーに確認する出力の目安:
colorfontFamilyfontWeightdimensionshadowduration判断原則:
保存後のメッセージ：
DESIGN.md をプロジェクトルートに保存しました。
[必要な場合のみ] W3C DTCG 形式の `design-tokens.json` も出力しました。
**次のステップ（推奨）:**
1. CLAUDE.md に `@DESIGN.md` を追記すると、AIが自動で参照します
2. Claude Design や他のトークン対応ツールに渡す場合は、最新仕様に合わせた `design-tokens.json` を併用できます
3. 使いながら気になった点があれば、いつでも修正してください
**この DESIGN.md を見直すタイミング:**
- 画面数が10を超えたとき（Component Patterns の拡充が必要になります）
- 新しい種類のUIパターンが出てきたとき（例: データ可視化、マルチステップフォーム）
- 3ヶ月以上経過したとき（Color Strategy や Typography の微調整）
見直したくなったら `/design-md:generate` を再実行してください。既存の内容を読んだうえで更新を提案します。
../../DESIGN-MD-SPEC.md — フォーマット仕様resources/writing-guide.md — 記述ガイド（Before/After）resources/examples/saas-dashboard.md — BtoB SaaS ダッシュボードの例resources/examples/creator-platform.md — クリエイタープラットフォームの例resources/examples/minimal-zen.md — ミニマル瞑想アプリの例（ミニマムレベル）セッション間のコンテキストを構造化して保存する。 「引き継ぎ」「セッション保存」「handoff」「コンテキスト保存」等で使用。 通常は自動保存（L1/L2）で十分。明示的に高品質な保存をしたいときに呼ぶ。
世の中のベストプラクティスをWeb検索・SNS検索・ツール検索で調査し、鮮度・信頼性・多角的視点を 考慮して構造化レポートにまとめる。「ベストプラクティスを調べて」「best practice」「最適な方法」 「推奨される方法」「どうするのが正解か調べて」「世の中ではどうやっているか」等で使用。 技術・ビジネス・教育・デザイン等あらゆるドメインに対応。
多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。