create-design-system-rules

デザインシステムのルールを作成する

概要

このスキルを使うと、プロジェクト固有のニーズに合わせたカスタムデザインシステムのルールを作成できます。このルールは、Figma デザインを実装する際に一貫性のある高品質なコードを Claude が生成できるよう導き、チームの慣習、コンポーネントのパターン、アーキテクチャ上の決定が自動的に守られるようにします。

デザインシステムのルールとは？

デザインシステムのルールとは、コードベースの「明文化されていない知識」を記述した、プロジェクトレベルの指示です。経験豊富な開発者が知っていて、新しいチームメンバーに伝えるような専門知識を指します。

• 使用するレイアウトのプリミティブとコンポーネント
• コンポーネントファイルの配置場所
• コンポーネントの命名方法と構成方法
• ハードコードしてはならないもの
• デザイントークンとスタイリングの扱い方
• プロジェクト固有のアーキテクチャパターン

これらのルールを定めると、繰り返しのプロンプトが大幅に減り、すべての Figma 実装タスクで一貫した出力が得られます。

前提条件

• Figma MCP サーバーに接続でき、アクセス可能であること
• 分析対象のプロジェクトのコードベースにアクセスできること
• チームのコンポーネントの慣習を理解していること（または、慣習を定める意思があること）

このスキルを使用するタイミング

次のような場合にこのスキルを使用してください。

• Figma デザインを使用する新しいプロジェクトを始めるとき
• 確立されたパターンがある既存のプロジェクトで Claude をオンボーディングするとき
• チーム全体で Figma からコードへのワークフローを標準化するとき
• 既存のデザインシステムの慣習を更新または調整するとき
• ユーザーが「デザインシステムのルールを作成して」「Figma のガイドラインを設定して」「プロジェクトに合わせてルールをカスタマイズして」と明示的に依頼したとき

必須のワークフロー

次の手順を順番どおりに実行してください。手順を省略しないでください。

ステップ 1：Create Design System Rules ツールを実行する

Figma MCP サーバーの create_design_system_rules ツールを呼び出し、基本となるプロンプトとテンプレートを取得します。

パラメーター：

• clientLanguages：プロジェクトで使用する言語のカンマ区切りリスト（例："typescript,javascript"、"python"、"javascript"）
• clientFrameworks：使用するフレームワーク（例："react"、"vue"、"svelte"、"angular"、"unknown"）

このツールは、デザインシステムのルールを作成するためのガイダンスとテンプレートを返します。ツールの応答で提供されるテンプレート形式に従って、デザインシステムのルールを構成してください。

ステップ 2：コードベースを分析する

ルールを確定する前に、プロジェクトの既存パターンを把握するため、コードベースを分析します。

コンポーネントの構成：

• UI コンポーネントはどこに配置されていますか？（例：src/components/、app/ui/、lib/components/）
• 専用のデザインシステムディレクトリはありますか？
• コンポーネントはどのように分類されていますか？（機能別、種類別、フラットな構成）

スタイリングの方法：

• どの CSS フレームワークまたは方法を使用していますか？（Tailwind、CSS Modules、styled-components など）
• デザイントークンはどこに定義されていますか？（CSS 変数、テーマファイル、設定ファイル）
• 色、タイポグラフィ、余白の既存トークンはありますか？

コンポーネントのパターン：

• どのような命名規則を使用していますか？（PascalCase、kebab-case、接頭辞）
• コンポーネントの props は通常どのように構成されていますか？
• 共通のコンポジションパターンはありますか？

アーキテクチャ上の決定：

• 状態管理はどのように行われていますか？
• どのルーティングシステムを使用していますか？
• 特定のインポートパターンやパスエイリアスはありますか？

ステップ 3：プロジェクト固有のルールを作成する

コードベースの分析に基づいて、包括的なルールを作成します。次の内容を含めてください。

一般的なコンポーネントのルール

- IMPORTANT: Always use components from `[YOUR_PATH]` when possible
- Place new UI components in `[COMPONENT_DIRECTORY]`
- Follow `[NAMING_CONVENTION]` for component names
- Components must export as `[EXPORT_PATTERN]`

スタイリングのルール

- Use `[CSS_FRAMEWORK/APPROACH]` for styling
- Design tokens are defined in `[TOKEN_LOCATION]`
- IMPORTANT: Never hardcode colors - always use tokens from `[TOKEN_FILE]`
- Spacing values must use the `[SPACING_SYSTEM]` scale
- Typography follows the scale defined in `[TYPOGRAPHY_LOCATION]`

Figma MCP 統合のルール

## Figma MCP Integration Rules

These rules define how to translate Figma inputs into code for this project and must be followed for every Figma-driven change.

### Required Flow (do not skip)

1. Run get_design_context first to fetch the structured representation for the exact node(s)
2. If the response is too large or truncated, run get_metadata to get the high-level node map, then re-fetch only the required node(s) with get_design_context
3. Run get_screenshot for a visual reference of the node variant being implemented
4. Only after you have both get_design_context and get_screenshot, download any assets needed and start implementation
5. Translate the output (usually React + Tailwind) into this project's conventions, styles, and framework
6. Validate against Figma for 1:1 look and behavior before marking complete

### Implementation Rules

- Treat the Figma MCP output (React + Tailwind) as a representation of design and behavior, not as final code style
- Replace Tailwind utility classes with `[YOUR_STYLING_APPROACH]` when applicable
- Reuse existing components from `[COMPONENT_PATH]` instead of duplicating functionality
- Use the project's color system, typography scale, and spacing tokens consistently
- Respect existing routing, state management, and data-fetch patterns
- Strive for 1:1 visual parity with the Figma design
- Validate the final UI against the Figma screenshot for both look and behavior

アセットの扱いに関するルール

## Asset Handling

- The Figma MCP server provides an assets endpoint which can serve image and SVG assets
- IMPORTANT: If the Figma MCP server returns a localhost source for an image or SVG, use that source directly
- IMPORTANT: DO NOT import/add new icon packages - all assets should be in the Figma payload
- IMPORTANT: DO NOT use or create placeholders if a localhost source is provided
- Store downloaded assets in `[ASSET_DIRECTORY]`

プロジェクト固有の慣習

## Project-Specific Conventions

- [Add any unique architectural patterns]
- [Add any special import requirements]
- [Add any testing requirements]
- [Add any accessibility standards]
- [Add any performance considerations]

ステップ 4：ルールを CLAUDE.md に保存する

作成したルールを、プロジェクトのルートにある CLAUDE.md ファイルに保存するようユーザーに案内します。

# MCP Servers

## Figma MCP Server Rules

[Paste generated rules here]

保存後、ルールは Claude Code によって自動的に読み込まれ、すべての Figma 実装タスクに適用されます。

Step 5: 検証と反復

ルールを作成したら、次の手順を行います。

1. シンプルな Figma コンポーネントの実装でテストします
2. Claude がルールに正しく従うことを確認します
3. 期待どおりに機能しないルールを調整します
4. チームメンバーに共有してフィードバックをもらいます
5. プロジェクトの進化に合わせてルールを更新します

ルールのカテゴリーと例

必須ルール（必ず含める）

コンポーネントの検出：

- UI components are located in `src/components/ui/`
- Feature components are in `src/components/features/`
- Layout primitives are in `src/components/layout/`

デザイントークンの使用：

- Colors are defined as CSS variables in `src/styles/tokens.css`
- Never hardcode hex colors - use `var(--color-*)` tokens
- Spacing uses the 4px base scale: `--space-1` (4px), `--space-2` (8px), etc.

スタイル設定の方法：

- Use Tailwind utility classes for styling
- Custom styles go in component-level CSS modules
- Theme customization is in `tailwind.config.js`

推奨ルール（非常に有用）

コンポーネントのパターン：

- All components must accept a `className` prop for composition
- Variant props should use union types: `variant: 'primary' | 'secondary'`
- Icon components should accept `size` and `color` props

インポート規約：

- Use path aliases: `@/components`, `@/styles`, `@/utils`
- Group imports: React, third-party, internal, types
- No relative imports beyond parent directory

コード品質：

- Add JSDoc comments for exported components
- Include PropTypes or TypeScript types for all props
- Extract magic numbers to named constants

任意のルール（プロジェクト固有）

アクセシビリティ：

- All interactive elements must have aria-labels
- Color contrast must meet WCAG AA standards
- Keyboard navigation required for all interactions

パフォーマンス：

- Lazy load images with the `Image` component from `@/components/Image`
- Use React.memo for components that receive complex props
- Icons should be SVG components, not icon fonts

テスト：

- Include unit tests for new components in `__tests__/` directory
- Use Testing Library queries (getByRole, getByLabelText)
- Test all interactive states and variants

例

例 1：React + Tailwind プロジェクト

ユーザー：「React プロジェクト向けのデザインシステムルールを作成して」

操作：

1. create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="react") を実行します
2. コードベースの構造を分析します
3. ルールを生成します。

# Figma MCP Integration Rules

## Component Organization

- UI components are in `src/components/ui/`
- Page components are in `src/app/`
- Use Tailwind for styling

## Figma Implementation Flow

1. Run get_design_context for the node
2. Run get_screenshot for visual reference
3. Map Figma colors to Tailwind colors defined in `tailwind.config.js`
4. Reuse components from `src/components/ui/` when possible
5. Validate against screenshot before completing

## Styling Rules

- IMPORTANT: Use Tailwind utility classes, not inline styles
- Colors are defined in `tailwind.config.js` theme.colors
- Spacing uses Tailwind's default scale
- Custom components go in `src/components/ui/`

## Asset Rules

- IMPORTANT: Use localhost sources from Figma MCP server directly
- Store static assets in `public/assets/`
- DO NOT install new icon libraries

4. プロジェクトのルートにある CLAUDE.md に保存します
5. シンプルなボタンの実装でテストします

結果： Claude は Figma デザインを実装する際に、プロジェクトの規約に一貫して従うようになります。

例 2：Vue + カスタム CSS プロジェクト

ユーザー：「Vue アプリ向けの Figma ルールを設定して」

操作：

1. create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="vue") を実行します
2. プロジェクトが CSS モジュールとカスタムデザイントークンシステムを使用していることを検出します
3. ルールを生成します。

# Figma MCP Integration Rules

## Component Organization

- Components are in `src/components/`
- Composables are in `src/composables/`
- Vue SFC structure: <script setup>, <template>, <style scoped>

## Design Tokens

- IMPORTANT: All colors defined in `src/styles/tokens.css` as CSS variables
- Use `var(--color-primary)`, `var(--color-secondary)`, etc.
- Spacing: `var(--space-xs)` through `var(--space-xl)`
- Typography: `var(--text-sm)` through `var(--text-2xl)`

## Figma Implementation Flow

1. Run get_design_context and get_screenshot
2. Translate React output to Vue 3 Composition API
3. Map Figma colors to CSS variables in `src/styles/tokens.css`
4. Use CSS Modules for component styles
5. Check for existing components in `src/components/` before creating new ones

## Styling Rules

- Use CSS Modules (`.module.css` files)
- IMPORTANT: Reference design tokens, never hardcode values
- Scoped styles with CSS modules

4. プロジェクトのルートにある CLAUDE.md に保存します
5. カードコンポーネントで検証します

結果： Claude はプロジェクトのデザイントークンシステムを使用して、Figma デザインを Vue コンポーネントに正しく変換するようになります。

例 3：デザインシステムチーム

ユーザー：「デザインシステムライブラリ向けのルールを生成して」

操作：

1. create_design_system_rules(clientLanguages="typescript", clientFrameworks="react") を実行します
2. デザインシステムのパッケージを含むモノレポの構造を分析します
3. 包括的なルールを生成します。

# Design System Rules

## Repository Structure

- Design system components: `packages/design-system/src/components/`
- Documentation: `packages/docs/`
- Design tokens: `packages/tokens/src/`

## Component Development

- IMPORTANT: All components must be in `packages/design-system/src/components/`
- Component file structure: `ComponentName/index.tsx`, `ComponentName.stories.tsx`, `ComponentName.test.tsx`
- Export all components from `packages/design-system/src/index.ts`

## Design Tokens

- Colors: `packages/tokens/src/colors.ts`
- Typography: `packages/tokens/src/typography.ts`
- Spacing: `packages/tokens/src/spacing.ts`
- IMPORTANT: Never hardcode values - import from tokens package

## Documentation Requirements

- Add Storybook story for every component
- Include JSDoc with @example
- Document all props with descriptions
- Add accessibility notes

## Figma Integration

1. Get design context and screenshot from Figma
2. Map Figma tokens to design system tokens
3. Create or extend component in design system package
4. Add Storybook stories showing all variants
5. Validate against Figma screenshot
6. Update documentation

4. CLAUDE.md に保存し、チームに共有します
5. チームのドキュメントに追加します

結果： チーム全体が、Figma からデザインシステムにコンポーネントを追加する際に、一貫したパターンに従うようになります。

ベストプラクティス

シンプルに始めて、反復する

最初からすべてのルールを網羅しようとしないでください。最も重要な規約から始め、不整合に気づいたらルールを追加します。

具体的にする

「デザインシステムを使用する」の代わりに、次のように記述します。「必ず src/components/ui/Button.tsx の Button コンポーネントを、variant prop（'primary' | 'secondary' | 'ghost'）とともに使用する」

実行可能なルールにする

各ルールでは、避けるべきことだけでなく、Claude が何をすべきかを明確に示します。

良い例：「色は src/theme/colors.ts で定義されています。これらの定数をインポートして使用してください」 悪い例：「色をハードコードしないでください」

重要なルールには IMPORTANT を使う

絶対に違反してはならないルールには「IMPORTANT:」を付け、Claude が優先できるようにします。

- IMPORTANT: Never expose API keys in client-side code
- IMPORTANT: Always sanitize user input before rendering

理由を記載する

ルールが恣意的に見える場合は、その理由を説明します。

- Place all data-fetching in server components (reduces client bundle size and improves performance)
- Use absolute imports with `@/` alias (makes refactoring easier and prevents broken relative paths)

よくある問題と解決策

問題：Claude がルールに従わない

原因： ルールが曖昧すぎるか、IDE／MCP クライアントに正しく読み込まれていない可能性があります。

解決策：

• ルールをより具体的で実行可能なものにします
• ルールが正しい設定ファイルに保存されていることを確認します
• IDE または MCP クライアントを再起動して、ルールを再読み込みします
• 重要なルールに「IMPORTANT:」を付けます

問題：ルール同士が矛盾する

原因： ルールが矛盾しているか、内容が重複しています。

解決策：

• すべてのルールを見直し、矛盾がないか確認します
• 明確な優先順位を定めます
• 冗長なルールを削除します
• 関連するルールを、明確な単一の記述にまとめます

問題：ルールが多すぎて Claude の動作が遅くなる

原因： ルールが多すぎると、コンテキストのサイズと処理時間が増加します。

解決策：

• 一貫性の問題の 80％を解決する 20％のルールに集中します
• 適用されることがほとんどない、細かすぎるルールを削除します
• 関連するルールをまとめます
• 段階的開示を利用します（最初に基本ルールを提示し、高度なルールはリンク先のファイルに記載します）

問題：プロジェクトの進行に伴い、ルールが古くなる

原因： コードベースは変わっても、ルールが更新されません。

解決策：

• 定期的にルールを見直すスケジュールを設定します（月次または四半期ごと）
• アーキテクチャに関する決定が変更されたら、ルールを更新します
• ルールファイルをバージョン管理します
• コミットメッセージにルールの変更内容を記録します

デザインシステムのルールを理解する

デザインシステムのルールを設定すると、Claude が Figma のデザインを扱う方法が変わります。

ルールを設定する前：

• Claude はコンポーネント構造を推測します
• 実装ごとにスタイルの適用方法に一貫性がありません
• デザイントークンに一致しない値がハードコードされます
• コンポーネントが無作為な場所に作成されます
• プロジェクトの規約について、同じ説明を繰り返す必要があります

ルールを設定した後：

• Claude は規約に自動的に従います
• コンポーネントの構造とスタイルに一貫性が生まれます
• 最初からデザイントークンが適切に使用されます
• コンポーネントが適切に整理されます
• 同じプロンプトを繰り返す必要がなくなります

適切なルールの作成に費やした時間は、Figma の実装タスクのたびに大きな効果をもたらします。

その他のリソース

• Figma MCP サーバーのドキュメント
• Figma の変数とデザイントークン