Figma Create Design System Rules

# Create Design System Rules

## Overview

This skill helps you generate custom design system rules tailored to your project's specific needs. These rules guide AI coding agents to produce consistent, high-quality code when implementing Figma designs, ensuring that your team's conventions, component patterns, and architectural decisions are followed automatically.

### Supported Rule Files

| Agent | Rule File | |-------|-----------| | Claude Code | `CLAUDE.md` | | Codex CLI | `AGENTS.md` | | Cursor | `.cursor/rules/figma-design-system.mdc` |

## What Are Design System Rules?

Design system rules are project-level instructions that encode the "unwritten knowledge" of your codebase - the kind of expertise that experienced developers know and would pass on to new team members:

- Which layout primitives and components to use - Where component files should be located - How components should be named and structured - What should never be hardcoded - How to handle design tokens and styling - Project-specific architectural patterns

Once defined, these rules dramatically reduce repetitive prompting and ensure consistent output across all Figma implementation tasks.

## Prerequisites

- Figma MCP server must be connected and accessible - Access to the project codebase for analysis - Understanding of your team's component conventions (or willingness to establish them)

## When to Use This Skill

Use this skill when:

- Starting a new project that will use Figma designs - Onboarding an AI coding agent to an existing project with established patterns - Standardizing Figma-to-code workflows across your team - Updating or refining existing design system conventions - Users explicitly request: "create design system rules", "set up Figma guidelines", "customize rules for my project"

## Required Workflow

**Follow these steps in order. Do not skip steps.**

### Step 1: Run the Create Design System Rules Tool

Call the Figma MCP server's `create_design_system_rules` tool to get the foundational prompt and template.

**Parameters:**

- `clientLanguages`: Comma-separated list of languages used in the project (e.g., "typescript,javascript", "python", "javascript") - `clientFrameworks`: Framework being used (e.g., "react", "vue", "svelte", "angular", "unknown")

This tool returns guidance and a template for creating design system rules.

Structure your design system rules following the template format provided in the tool's response.

### Step 2: Analyze the Codebase

Before finalizing rules, analyze the project to understand existing patterns:

**Component Organization:**

- Where are UI components located? (e.g., `src/components/`, `app/ui/`, `lib/components/`) - Is there a dedicated design system directory? - How are components organized? (by feature, by type, flat structure)

**Styling Approach:**

- What CSS framework or approach is used? (Tailwind, CSS Modules, styled-components, etc.) - Where are design tokens defined? (CSS variables, theme files, config files) - Are there existing color, typography, or spacing tokens?

**Component Patterns:**

- What naming conventions are used? (PascalCase, kebab-case, prefixes) - How are component props typically structured? - Are there common composition patterns?

**Architecture Decisions:**

- How is state management handled? - What routing system is used? - Are there specific import patterns or path aliases?

### Step 3: Generate Project-Specific Rules

Based on your codebase analysis, create a comprehensive set of rules. Include:

#### General Component Rules

```markdown - 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]` ```

#### Styling Rules

```markdown - 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 Integration Rules

```markdown ## 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

###