create-design-system

ユーザーが既存のブランド、コードベース、または製品をもとに、再利用可能なデザインシステムや UI キットの作成を求めたときに読み込まれます。

デザインシステムの配置場所

プロジェクトのすべてのデザインシステムは、./opendesign/design-systems/<name>/ の下に配置します。複数のシステムを共存させることができます。たとえば、./opendesign/design-systems/marketing/、./opendesign/design-systems/product/、./opendesign/design-systems/deck-template/ のように配置できます。名前は必須で、システムの用途（ブランドの適用範囲、製品の適用範囲、デッキテンプレート、共同ブランドパートナー）を表すものにします。単数形の design-system/ や、main のような汎用的な名前は使用しないでください。

フォルダーに SKILL.md またはトークンファイル（ルートにある colors_and_type.css、あるいはネストされた tokens/colors_and_type.css）のいずれかが含まれている場合、そのフォルダーはデザインシステムとして認識されます。システムを検出するとき、opendesign はどちらのマーカーも受け付けます。必ず両方を作成してください。SKILL.md があればフォルダーを単独で持ち運べるエージェントスキルとして使え、トークンファイルはこのスキルの標準出力になります。

必須パス（厳守）

生成するすべてのシステムは、プロジェクトルートからの相対パスとして、必ず以下の正確なパスに書き込んでください。opendesign の自動検出はこれらのパスに依存しているため、変更すると検出が機能しなくなります。

• ./opendesign/design-systems/<name>/SKILL.md — スキルを持ち運べることを示すマーカー。
• ./opendesign/design-systems/<name>/tokens/colors_and_type.css — 標準トークンファイル。tokens/ の下にネストし、フォルダーのルートには置きません。これは検出マーカーです。
• ./opendesign/design-systems/<name>/README.md — 人が読むためのインデックス。

トークンファイルを別のパスに書き込まないでください（colors.css、styles/tokens.css、システムフォルダーのルートに置く colors_and_type.css は不可）。SKILL.md を省略しないでください。opendesign/ 内の親フォルダー design-systems/ の名前を変更しないでください。

デザインシステムのフォルダーに含めるもの

opendesign/design-systems/<name>/
  README.md
  tokens/
    colors_and_type.css
  fonts/
    [font files the brand actually ships]
  assets/
    logos/
    icons/
    imagery/
  brand/
    voice-and-tone.md
    style-notes.md
  ui-kit-<product>/
    components/        # JSX components, one per file
    index.html         # interactive showcase of core screens
  sample-slides/       # only if a deck template was provided

手順

1. 提供されたアセットを調査します。 コードベース、Figma ファイル（利用できる場合はデザインコンテキスト API 経由）、スクリーンショット、デッキを確認します。あらゆる場合において、スクリーンショットよりもコードベースのソースと Figma データを優先します。
2. README を作成します。 ブランドについての理解を記載し、参照したすべてのソースを列挙して、フォルダー内の各項目へのインデックスを用意します。
3. トークンを抽出します。 カラーとタイポグラフィのトークンを、必ず ./opendesign/design-systems/<name>/tokens/colors_and_type.css に書き込みます。フォルダーのルートではなく、ファイル名も変更しないでください。また、フォルダーが認識され、持ち運び可能になるように ./opendesign/design-systems/<name>/SKILL.md も作成します。生の変数（--fg-1、--fg-2、--bg-1、--accent-1、フォントファミリー、ウェイト、サイズ段階）と意味的な変数（--h1、--h2、--body、--caption、--surface-primary、--border-subtle など）を定義します。意味的な変数は生の変数を参照します。
4. コンテンツの基本要素を文書化します。 声調、トーン、大文字・小文字の使い分け（タイトルケースとセンテンスケース）、句読点のルール、絵文字の使用、数値の書式、ブランドがユーザーに語りかける方法とブランド自身について語る方法を記載します。
5. ビジュアルの基盤を文書化します。 カラー（単なる色見本ではなく役割）、タイポグラフィ（スケール、組み合わせ、使用ルール）、スペーシング（スケールと適用場面）、背景（処理方法とそれぞれの使用場面）、モーション（タイミング、イージング、一般的なパターン）、ホバーと押下の状態、ボーダー、シャドウ、角丸、カードのパターン、画像の雰囲気を記載します。
6. アイコノグラフィを文書化します。 アイコンフォント、SVG スプライト、ラスターアセット、絵文字のポリシー、Unicode の使用方法を記載します。実際のアセットファイルを assets/ にコピーしてください。手描きはしないでください。
7. 製品ごとに UI キットを構築します。 既存のコンポーネントをピクセル単位で忠実に再現し、トークン駆動の JSX として、1 ファイルにつき 1 コンポーネントで作成します。キットを操作しながら確認できるよう、主要な画面を組み立てた index.html を用意します。
8. サンプルスライドを作成します。 デッキテンプレートが提供された場合に限ります。デッキスキルの規約に従ってください。

厳守事項

• コードベースを利用できる場合、スクリーンショットだけをもとに UI を再現しないでください。正とするのはコードベースです。スクリーンショットは情報が欠落しています。
• SVG のソースファイルを読まないでください。メリットがない一方で、コンテキストを消費します。ファイルを assets/ にコピーし、ファイル名で参照してください。
• SVG を手描きしないでください。実際のアセットをコピーしてください。
• コンポーネントを作り出さないでください。UI キットでは、実在するものを再現します。ソースにないコンポーネントは省くか、ラベル付きのプレースホルダーで代用してください。独自の解釈で不足を補わないでください。
• コードベース、Figma ファイル、ブランドガイドラインなどの重要なリソースにアクセスできない場合は、作業を止めて確認してください。推測で進めないでください。
• 業界で使い古されたビジュアルモチーフを安易に使わないでください。青みがかった紫のグラデーション、機能カードに絵文字を使うデザイン、色付きの左側アクセントラインを付けた角丸カードなどが該当します。

作業の締めくくり

最後に、内容を確認してもらうための明確な依頼を添えてください。確信が持てた部分、不確かな部分、システムの標準仕様とする前にユーザーに確認したい決定事項を列挙してください。