Figma Create Design System Rules

• 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

- 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

- 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

## 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 Rules

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

## 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]

Step 4: Save Rules to the Appropriate Rule File

Detect which AI coding agent the user is working with and save the generated rules to the corresponding file:

If unsure which agent the user is working with, check for existing rule files in the project or ask the user.

For Cursor, wrap the rules with YAML frontmatter:

---