Create Design System Rules Overview

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

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 Claude 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 CLAUDE.md

Guide the user to save the generated rules to the CLAUDE.md file in their project root:

MCP Servers

Figma MCP Server Rules

[Paste generated rules here]

After saving, the rules will be automatically loaded by Claude Code and applied to all Figma implementation tasks.

Step 5: Validate and Iterate

After creating rules:

Test with a simple Figma component implementation Verify Claude follows the rules correctly Refine any rules that aren't working as expected Share with team members for feedback Update rules as the project evolves Rule Categories and Examples Essential Rules (Always Include)

Component Discovery:

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

Design Token Usage:

• 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.

Styling Approach:

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

Recommended Rules (Highly Valuable)

Component Patterns:

• 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

Import Conventions:

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

Code Quality:

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

Optional Rules (Project-Specific)

Accessibility:

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

Performance:

• 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

Testing:

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

Examples Example 1: React + Tailwind Project

User says: "Create design system rules for my React project"

Actions:

Run create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="react") Analyze codebase structure Generate rules:

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

Save to CLAUDE.md in project root Test with a simple button implementation

Result: Claude now consistently follows the project's conventions when implementing Figma designs.

Example 2: Vue + Custom CSS Project

User says: "Set up Figma rules for my Vue app"

Actions:

Run create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="vue") Discover that project uses CSS modules and a custom design token system Generate rules:

Figma MCP Integration Rules

Component Organization

• Components are in src/components/
• Composables are in src/composables/
• Vue SFC structure: