フロントエンドコードからデザインシステムを抽出

フロントエンドコードからデザインシステムを抽出 は何をしますか？

フロントエンドのソースコードを解析して、プロジェクトのビジュアル言語（カラー、タイポグラフィ、スペーシング、コンポーネントパターン、レイアウト原則）を捉えた包括的なデザインシステムドキュメント（DESIGN.md）を抽出します。アプリケーションをビルドしたりレンダリングしたりする必要はありません。

なぜこれが必要か

design-mdスキルはレンダリングされたHTMLから動作します。しかし、アプリを実行する前にコードベースのデザインシステムを理解したい場合がよくあります。依存関係が不足していたり、ビルドが壊れていたり、簡単な監査をしたいだけかもしれません。このスキルはソースファイル自体（スタイルシート、コンポーネントファイル、テーマ設定、Tailwindの設定）を読み取ります。より高速で、どこでも動作します。

いつ使用するか

• ユーザーがフロントエンドのコードベースを持っており、そのデザインシステムを抽出または文書化したい場合
• ユーザーがプロジェクトのビジュアルアイデンティティをStitchに移行したい場合
• ユーザーが「スタイルを監査する」または「リポジトリのデザイン言語を理解する」ように依頼した場合
• ユーザーが既存のソースコードからDESIGN.mdを作成したい場合
• アプリをビルド/レンダリングできないが、ソースは利用可能な場合
• ユーザーがコードベース全体の矛盾するスタイルを統一または調整したい場合

前提条件

• フロントエンドプロジェクトのソースディレクトリへのアクセス
• ビルドやランタイムの依存関係は不要 — このスキルはソースファイルのみを読み取ります

---

ワークフロー

フェーズ 1: プロジェクトの発見

まず、何を扱っているのかを理解します。これにより、使用する抽出パターンが決まります。

1. フレームワークとスタックの検出

プロジェクトルートで特徴的なファイルをスキャンします：

シグナルファイル	フレームワーク / ツール
package.json に react あり	React / Next.js
package.json に vue あり	Vue / Nuxt
package.json に svelte あり	Svelte / SvelteKit
package.json に @angular/core あり	Angular
tailwind.config.js/ts	Tailwind CSS
postcss.config.js	PostCSS パイプライン
styled-components または @emotion が依存関係に	CSS-in-JS
.css / .scss / .less ファイルのみ	プレーンCSS / SASS
theme.js / theme.ts / tokens.js	デザイントークンファイル

最初に package.json を読みます。フレームワーク、CSSツール、およびデザイントークンライブラリ（例：style-dictionary、@chakra-ui/react、@mui/material、ant-design）が明らかになります。このコンテキストから、スタイル情報をどこで探すべきかがわかります。

2. ソースツリーのマッピング

分析する主要なディレクトリとファイルを特定します：

src/
├── components/     ← コンポーネントレベルのスタイル
├── styles/         ← グローバルスタイルシート
├── theme/          ← テーマ定義、トークン
├── assets/         ← フォント、画像
├── app.css         ← ルートスタイル
└── index.css       ← エントリーCSS

以下も確認します：

• tailwind.config.js / tailwind.config.ts — カスタムカラー、フォント、スペーシング
• globals.css / global.css — CSSカスタムプロパティ（変数）
• 任意の theme.* または tokens.* ファイル
• コンポーネントライブラリの設定（例：chakra-theme.ts、vuetify.config.ts）

3. フレームワーク固有のガイダンスを参照

抽出パターンについて適切なリファレンスを参照します：

• React / Next.js / Tailwind → references/react-tailwind.md
• Vue / Nuxt → references/vue.md
• Svelte / SvelteKit → references/svelte.md
• Angular → references/angular.md
• プレーンCSS / SASS / Less → references/plain-css.md

これらのリファレンスには、カラー、タイポグラフィ、スペーシング、コンポーネントスタイルを特定するためのフレームワーク固有のパターンが含まれています。先に進む前に、該当するものを読んでください。

---

フェーズ 2: 詳細抽出

各デザインの次元を体系的に処理します。それぞれについて、ソースファイルから生データを収集し、それを説明的な言語に統合します。

目標はすべてのCSSプロパティをダンプすることではなく、スタイル選択の意図を理解し、別のデザイナー（またはStitch）が同じビジュアルフィールを再現できるように、人間的で編集的な言語で記述することです。

1. ビジュアルテーマと雰囲気

まず最も広いスタイルを読んで、全体的なムードを理解します：

• ルートの背景: body またはルート要素の背景は何ですか？ 明るいクリーム系（#fレンジ）は軽やかでクリーン、ダーク系（#0-#2レンジ）はムーディーでドラマチックです。
• ホワイトスペースの哲学: スペーシングの値は寛大（32px以上）ですか、それともタイトですか？ ルートコンテナ、セクションラッパー、カードコンポーネントの padding/margin 値を確認します。
• 密度: ページ/セクションごとのコンポーネント数を数えます。少なくスペースがある = ミニマル、多く詰まっている = 情報密度が高い。
• 色温度: ニュートラルは暖色（クリーム、タン）ですか、寒色（ブルーグレー、スレート）ですか？
• 全体的な雰囲気: ムードを捉えた1〜2の豊かな文章に統合します。

これらのシグナルをソース内で探します：

ソースの場所	何がわかるか
ルート background-color またはレイアウトの Tailwind bg-*	全体的な明るさ/暗さ
Tailwind設定またはCSS変数のスペーシングスケール	ホワイトスペースの哲学
コンポーネント数 vs ラッパーのpadding	密度
カスタムプロパティの命名（--warm-* vs --cool-*）	色温度の意図
テーマファイルのコメント	開発者自身の言葉によるデザイン意図

2. カラーパレットと役割

コードベースからすべてのユニークなカラーを抽出し、機能的な役割を割り当てます。すべてのレイヤーを検索します：

色を見つける場所：

レイヤー	検索するもの
CSSカスタムプロパティ	--color-*、--primary、--bg-*
Tailwind設定	theme.extend.colors
テーマ/トークンファイル	カラーオブジェクト、パレット
コンポーネントスタイル	background-color、color、border-color
インライン/スコープスタイル	テンプレート内の bg-*、text-* クラス
CSS-in-JS テーマオブジェクト	colors、palette キー

整理方法： 色相ではなく機能で色をグループ化します：

1. プライマリファンデーション — 背景とサーフェスの色
2. アクセントとインタラクティブ — CTAボタン、アクティブ状態、リンク
3. タイポグラフィとテキスト階層 — プライマリ、セカンダリ、ターシャリテキスト
4. 機能状態 — 成功、エラー、警告、情報

各色について、生のhex値ではなく、その色の特徴を呼び起こす説明的な名前を作成します：

• ❌ #294056 → 「青」
• ✅ #294056 → 「深みのあるミュートされたティールネイビー」 — プライマリCTA、アクティブナビゲーション

重複排除が重要です。 コードベースにはしばしばほぼ同一の色（例：#333 と #2C2C2C）があります。意図された色を最もよく表す1つの名前に統合します。

3. タイポグラフィルール

完全なタイポグラフィシステムを抽出します：

フォントファミリー：

• CSS font-family、Tailwind fontFamily、Google Fontsへのリンク、またはローカルの @font-face 宣言を確認します。
• 各フォントの特徴に注目します：幾何学的 vs ヒューマニスト、セリフ vs サンセリフ、それが呼び起こす感覚。

タイプスケール（階層）：

• すべての見出しレベル（H1〜H6）と本文テキストを見つけ、以下を記録します：
  • font-size（remまたはpx）
  • font-weight（数値 + 説明的な名前）
  • letter-spacing（そしてその理由 — エレガンス？ コンパクトさ？）
  • line-height（読みやすさのために寛大？ ディスプレイ用にタイト？）
• コンポーネントの使用法をマッピングします：プロダクトカードではどの見出しレベルが使われていますか？ ヒーローセクションでは？

スペーシングの原則：

• テキストのスペーシングは、全体的なスペーシングスケールとどのように関連していますか？
• 見出しと本文での letter-spacing パターン
• line-height の哲学（本文には寛大/リラックス、ディスプレイにはタイト）

4. コンポーネントスタイリング

最も重要な4〜5つのUIプリミティブを分析します：

ボタン：

• コーナー半径（そしてそれが何を伝えるか — 遊び心？ プロフェッショナル？ ミニマル？）
• プライマリ、セカンダリ、ゴーストバリアントのカラースキーム
• ホバー/フォーカス/アクティブ状態とトランジションのタイミング
• パディング比率（水平 vs 垂直）

カード / コンテナ：

• コーナー半径（多くの場合、ボタンとは異なり、少し丸い）
• シャドウ戦略：フラット、微妙なホバーシャドウ、または常に浮いている？
• ボーダーの処理：ヘアラインボーダー、カラーのアクセント、またはなし？
• 内部パディング（寛大かコンパクトか？）
• カード内の画像の扱い（フルブリード、パディングあり、角丸？）

ナビゲーション：

• レイアウトパターン（水平バー、垂直サイドバー、ドロワー）
• タイポグラフィの処理（大文字、letter-spacing、ウェイト）
• アクティブ/ホバー状態のインジケーター（下線、色、背景）
• モバイルでの動作（ハンバーガー、ボトムナビ、ドロワー）

入力とフォーム：

• ボーダースタイルとフォーカス状態の動作
• ボタンとのコーナースタイルの一貫性
• パディングとタッチターゲットのサイズ

ドメイン固有のコンポーネント：

• このプロジェクトに固有の1〜2のコンポーネント（例：プロダクトカード、ダッシュボードウィジェット、チャットバブル）を特定し、そのスタイリングパターンを記述します。

5. レイアウト原則

構造的なシステムを抽出します：

グリッドと構造：

• 最大コンテンツ幅（コンテナの max-width から）
• カラムシステム（CSS Grid、Flexboxパターン、定義されたブレークポイント）
• レスポンシブブレークポイント（メディアクエリまたはTailwind設定から）

ホワイトスペース戦略：

• ベーススペーシングユニット（8pxグリッド？ 4px？ カスタム？）
• セクションマージン（主要セクション間のスペース量）
• エッジパディング（異なるブレークポイントでのページマージン）

配置と視覚的バランス：

• テキスト配置パターン（中央揃えのヒーロー、左揃えの本文）
• 画像とテキストの比率
• 視覚的な重みの分布

レスポンシブ動作：

• モバイルファーストですか、デスクトップファーストですか？
• グリッドはどのように折りたたまれますか？ パディングスケールは？
• タッチターゲットのサイズ

6. Stitch生成用ノート

抽出をStッチのための実行可能なプロンプトに統合します：

• 雰囲気の言語: ムードを自然な記述子に変換します
• カラーリファレンス: 説明的な名前とhexで色をリストします
• コンポーネントプロンプト: Stitchで主要コンポーネントを再現するための2〜3の例のプロンプトを書きます
• 反復ガイダンス: このデザインシステムで画面を洗練するためのヒント

---

フェーズ 3: DESIGN.md を書く

すべてを標準のDESIGN.md形式にまとめます。プロジェクトディレクトリの .stitch/DESIGN.md に配置します（.stitch/ ディレクトリが存在しない場合は作成します）。

[!IMPORTANT] You MUST include the YAML frontmatter at the top of the file with name and colors mapping, exactly as shown in the example at examples/DESIGN.md. This structured data is required for other skills to parse the design system.

Failure to include this YAML block with at least the core color tokens is a failure to use this skill correctly.

examples/DESIGN.md の例の形式をテンプレートとして使用します。ファイルはYAMLブロックで始まり、その後にマークダウンセクションが続く必要があります：

# Design System: [プロジェクト名]
**Project ID:** [既知の場合は、それ以外は省略]

## 1. Visual Theme & Atmosphere
[ムード、哲学、主要な特性を説明する豊かな2段落]

## 2. Color Palette & Roles
### Primary Foundation
### Accent & Interactive
### Typography & Text Hierarchy
### Functional States

## 3. Typography Rules
### Hierarchy & Weights
### Spacing Principles

## 4. Component Stylings
### Buttons
### Cards & [ドメイン固有のコンテナ]
### Navigation
### Inputs & Forms
### [ドメイン固有のコンポーネント]

## 5. Layout Principles
### Grid & Structure
### Whitespace Strategy
### Alignment & Visual Balance
### Responsive Behavior & Touch

## 6. Design System Notes for Stitch Generation
### Language to Use
### Color References
### Component Prompts
### Incremental Iteration

---

フェーズ 4: 統合（オプション）

ユーザーがデザインシステムをStitchにプッシュしたい場合：

1. MCPの作成/更新呼び出しのために manage-design-system スキルに引き継ぎます
2. あなたが作成したDESIGN.mdが入力となり、manage-design-systemスキルがStitch APIの統合を処理します

ユーザーがドキュメントだけを欲しい場合は、フェーズ3の後に完了です。

---

品質チェックリスト

DESIGN.mdを提供する前に、以下を確認します：

• すべての色に説明的な名前、16進コード、機能的な役割がある
• タイポグラフィにフォントファミリー、文字の説明、完全な階層が含まれている
• コンポーネントスタイルが形状、色、状態、トランジションを記述している
• レイアウトに最大幅、グリッド、ブレークポイント、スペーシング戦略が含まれている
• Stitch生成ノートがCSS構文ではなく自然言語を使用している
• 雰囲気セクションが技術文書ではなく編集コピーのように読める
• ほぼ重複した色が統合されている
• ドキュメントが生の値だけでなく、スタイリングの意図を捉えている

抽出を向上させるためのヒント

• コメントとコミットメッセージを読んでください。 開発者はデザインの意図をコードコメント（/* hero section — breathable */）やコミットメッセージに文書化することがよくあります。これらはなぜを理解するための金鉱です。
• デザイントークンライブラリを確認してください。 プロジェクトが style-dictionary、@tokens-studio などを使用している場合、これらのファイルはデザイン値の最も信頼できる情報源です。
• テーマファイルはコンポーネントスタイルよりもシグナルが強いです。 パレットを定義する theme.ts は意図されたデザインシステムを示しますが、コンポーネントに散在するインラインスタイルは実際に出荷されたものを示します。両方とも重要ですが、テーマから始めてください。
• Tailwind設定はデザインシステムです。 プロジェクトにカスタマイズされた tailwind.config.js がある場合、それ自体がデザインシステムです — 最初にそこから抽出し、コンポーネントでオーバーライドがないかスポットチェックします。
• CSSカスタムプロパティは意図的です。 開発者が --brand-primary を定義した場合、これがデザイントークンであることを示しています。それを尊重してください。