design-md-creator

name	design-md-creator
description	対象ブランドのサイトURL、VI PDF、リポジトリの既存コードを入力として、awesome-design-md 準拠の9セクション構成で自己完結型の DESIGN.md を生成するスキル。DESIGN.md を新規作成したいとき、既存の DESIGN.md を更新・改善したいとき、サイトやPDFからデザイントークンを抽出して整理したいとき、AIエージェント向けのデザイン参照ファイルが必要なとき、ブランドガイドラインや VI（ビジュアルアイデンティティ）をコード実装に橋渡ししたいときに使う。

DESIGN.md Creator

概要

入力ソース（サイト URL、VI PDF、リポジトリのコード）からデザイン特性を抽出し、awesome-design-md 準拠の9セクション構成で DESIGN.md を生成する。入力は1つでも複数の組み合わせでも動作する。生成後は客観レビューと自己修正を1パス入れてから完成させる。

基本原則

• 先に抽出し、後から構成する。DESIGN.md は推測ではなく入力ソースの事実を変換した結果。
• 記述的 > 技術的。"Deep Ocean (#1A73E8) — 主要ボタン・リンク" のように、自然言語名 + hex 値 + 機能的役割を含める。
• トークンレベルのみ扱う。デザインシステム全文の転記や実装コードの貼り付けはしない。
• 技術値を自然言語で補足する（"rounded-full" → "ピル型(9999px)"、"shadow-lg" → "浮き上がり強め"）。
• 具体値（hex, px, font-family）を省略しない。"blue" や "rounded" だけで終わらせない。
• 既存の DESIGN.md がある場合は、上書きではなく差分更新を提案する。
• 生成して終わらず、完成前に必ず客観レビューと自己修正を1パス入れる。

進め方

1. 入力ソースの特定と言語判断

   ユーザーから提供された入力（サイト URL、VI PDF パス、リポジトリパス）を確認する。どれが利用可能かを把握し、必要な補足情報はユーザーに確認する。対象コンテンツに日本語が含まれるかを判断する（後のステップで使う）。

2. テンプレートの確認

   references/template.md を読み、9セクション構成と各セクションの記述ガイドを把握する。

3. 入力ソースからデザイン特性を抽出する

   利用可能な入力すべてから抽出し、情報を統合する。詳細は「入力ソース別の抽出手順」を参照。

4. 抽出情報を整理する

   • 色: セマンティック名 + hex 値 + 機能的役割
   • タイポグラフィ: font-family、ウェイト、サイズ階層、行間
   • スペーシング: 余白体系、グリッド、コンテナ幅
   • 角丸・影・ボーダー: 技術値を自然言語に変換
   • コンポーネントスタイル: ボタン・カード・入力の共通パターン

5. 日本語拡張（日本語コンテンツがある場合のみ）

   ステップ1で日本語コンテンツが確認された場合のみ references/japanese-typography.md を読み、Typography Rules セクションに和文フォント・行間・禁則処理・OpenType 機能を追加する。

6. 9セクションを組み立てる

   references/template.md の構成に従い DESIGN.md を生成する。セクションヘッダーは英語。実際の記述例は references/examples.md を参考にする。情報が不足するセクションは推測で埋めず「要補完:」と明示する。

7. 客観レビューと自己修正

   references/best-practices.md のルブリック8項目を yes/no で判定する。no が出た項目は優先順位に従ってその場で修正する。修正不可能な問題（入力ソースに情報がない等）はユーザーへの確認事項として報告する。

8. 仕上げの確認

   • 9セクション全てに具体記述があるか
   • 全ての色に hex 値・名前・役割があるか
   • フォント名は実在するか（推測で書いていないか）
   • 技術値に自然言語の補足があるか
   • 既存 DESIGN.md の更新なら、残すべき内容と削るべき重複を分けて処理したか

入力ソース別の抽出手順

A. サイト URL が提供された場合

利用可能なツール（WebFetch 等）で対象 URL の HTML を取得する。取得に失敗した場合は利用可能な代替手段で対象サイトの情報を収集する。

抽出対象:

• <style> タグや外部 CSS から CSS カスタムプロパティ（--color-*、--font-* 等）
• <link> タグからフォント読み込み（Google Fonts、Adobe Fonts 等）
• meta[name="viewport"] からレスポンシブ設定
• 主要要素のクラス名からデザインシステムの傾向（Tailwind、CSS Modules 等）
• ページの視覚的印象（Visual Theme & Atmosphere 用）

B. VI PDF が提供された場合

Read ツールで PDF を読み込む（20ページ制限に注意）。20ページを超える場合:

1. まず最初の数ページ（目次ページ等）を読み、色・タイポグラフィ・ロゴ使用規定のページを特定する
2. pages パラメータを指定して該当ページのみを読み込む

抽出対象:

• ブランドカラー（Primary、Secondary、Accent の定義）
• 指定フォント
• ロゴ周辺の余白規定（Layout Principles に反映）
• Do's and Don'ts（VI に記載があればそのまま反映できることが多い）
• ブランドの世界観・哲学記述（Visual Theme & Atmosphere に反映）

C. リポジトリの既存コードが利用可能な場合

以下のファイルを検索して読む:

tailwind.config.{js,ts,mjs}     # theme 設定から色・フォント・スペーシング・角丸・影
*.css, *.scss                    # カスタムプロパティ、変数定義（globals.css, variables.css 等）
design-tokens.{json,yaml}        # デザイントークン JSON/YAML
tokens.{json,yaml}               # 同上
DESIGN.md                        # 既存の DESIGN.md（更新の場合）
package.json                     # フォント関連パッケージ（@fontsource/* 等）

抽出対象:

• theme.colors、theme.fontSize、theme.spacing、theme.borderRadius、theme.boxShadow
• CSS カスタムプロパティの定義
• 実際のコンポーネントで使われているスタイルのパターン

統合ルール

複数のソースで同一トークンが見つかった場合:

コード > VI PDF > サイト の優先順で採用する（コードが最新の実装を反映するため）。

ソース間で矛盾がある場合はユーザーに確認する。

生成後レビュー

生成した DESIGN.md を「自分が書いた文書」ではなく「他人が置いた draft」として査読する。まず削るべき情報・外へ逃がすべき情報がないかを見てから、足りない情報を考える。

references/best-practices.md のルブリック8項目（specificity / roles / completeness / consistency / descriptiveness / japanese / brevity / agent-ready）を yes/no で判定し、no が出た項目を優先順位に従ってその場で反映する。

書かないこと

• 修飾なしの一般用語（"blue" だけ、"rounded" だけ）
• 入力ソースから確認できない推測
• 実装コード（CSS クラスリスト、Tailwind クラス名そのもの）
• バイナリアセット（ロゴ、アイコン）のインライン記述
• デザインシステム全文の転記
• 古くなりやすい一時的な値

仕上げの確認

• 9セクション全てに1項目以上の具体記述があるか
• ルブリックの no 項目を全て修正し終えたか
• 情報不足のセクションを「要補完:」と明示したか
• 既存 DESIGN.md の更新なら差分更新になっているか