Figma Create Design System Rules
Generate agent-specific design system rule files so Figma-to-code work follows your components, tokens, and folder conventions.
Overview
figma-create-design-system-rules is an agent skill most often used in Build (also Ship review) that generates project-specific Figma-to-code rule files for Claude, Codex, and Cursor.
Install
npx skills add https://github.com/figma/mcp-server-guide --skill figma-create-design-system-rulesWhat is this skill?
- Tailors rules to Claude Code (CLAUDE.md), Codex (AGENTS.md), and Cursor (.cursor/rules/figma-design-system.mdc)
- Encodes layout primitives, naming, file locations, and anti-hardcoding guidance
- Covers design tokens, styling, and project-specific architectural patterns
- Requires an active Figma MCP server connection
- Turns tacit senior-dev design knowledge into persistent agent instructions
- Three supported agent rule targets: CLAUDE.md, AGENTS.md, .cursor/rules/figma-design-system.mdc
Adoption & trust: 1.6k installs on skills.sh; 1.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Agents implementing Figma screens invent inconsistent components and styles because your design system conventions live only in reviewers’ heads.
Who is it for?
Builders with Figma MCP connected who want one-time setup of durable design rules before agents write UI code.
Skip if: Projects with no Figma workflow, no MCP connection, or purely backend work with no design handoff.
When should I use this skill?
User says create design system rules, generate rules for my project, set up design rules, customize design system guidelines, or wants Figma-to-code conventions with Figma MCP.
What do I get? / Deliverables
You get committed rule files that steer agents toward your primitives, tokens, and file structure on every Figma implementation pass.
- CLAUDE.md, AGENTS.md, or .cursor/rules/figma-design-system.mdc content
- Documented component, token, and layout conventions for agents
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
First appears in Build when you are setting conventions before agents implement UI from Figma. frontend is the canonical shelf for design-to-code rules, tokens, and component placement even though rules also help later reviews.
Where it fits
Bootstrap CLAUDE.md rules before the first sprint of Figma frame implementation.
Document where components live so new contributors and agents share one map.
Refresh rules after a token rename so review comments match enforced agent behavior.
How it compares
Skill package for authoring rules—not the Figma MCP server itself and not a pixel-perfect export tool.
Common Questions / FAQ
Who is figma-create-design-system-rules for?
Solo frontend leads and indie SaaS teams using Figma plus Claude Code, Cursor, or Codex who need repeatable design-to-code guardrails.
When should I use figma-create-design-system-rules?
In Build before heavy UI implementation; in Ship when tightening review consistency; skip if you are not connecting agents to Figma via MCP.
Is figma-create-design-system-rules safe to install?
It writes project rule files and uses MCP network access to Figma; review the Security Audits panel on this page and scope MCP credentials appropriately.
SKILL.md
READMESKILL.md - 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: Alwa