Preface¶

When using AI coding tools to turn Figma designs into frontend code, the common problem is rarely “can’t write it out” but rather “the code doesn’t match your project’s conventions”. Casual spacing, hardcoded hex colors, components dumped into random directories, recreating a Button component when one already exists in the repo—these are all classic signs that the design system only exists as a verbal team agreement and hasn’t been added to the Agent’s readable context.

figma-create-design-system-rules is the Agent Skill built for this exact purpose: it doesn’t draw interfaces directly, but instead analyzes your codebase, generates a set of design system rules tied to your project’s conventions, and saves them into the rule files that Cursor / Codex CLI / Claude Code will load automatically. When you later implement designs from Figma, the Agent will follow these rules instead of needing you to repeatedly remind it “don’t hardcode colors” every time.

What is this¶

One-sentence positioning: Generates custom design system rules for the current project to constrain the Agent’s component selection, styling practices, and directory structure during the Figma-to-code workflow.

This Skill is included in the OpenAI openai/skills repository under the skills/.curated/figma-create-design-system-rules directory. The LICENSE.TXT in the directory states that the materials are governed by the Figma Developer Terms, and it is a capability wrapper provided by Figma for Agent / MCP scenarios. The official Figma MCP documentation also separately covers the同名 capability: create_design_system_rules, which is used to produce rule files that guide design-to-code translation.

The prerequisites are clear: you need a connected and available Figma MCP Server, and the Agent must be able to read your project codebase to ensure the rules are tailored to your specific setup.

Trigger scenarios include (consistent with the Skill description):
- Saying “create design system rules”, “generate rules for my project”, “set up design rules”, “customize design system guidelines”
- Preparing a new project for long-term Figma-driven development
- Onboarding an existing codebase’s Agent by formalizing team conventions
- Standardizing the team’s Figma-to-code workflow or iterating on existing design agreements

Core Features and Highlights¶

Turn “unwritten conventions” into Agent-readable rules¶

The official documentation defines Design System Rules as project-level instructions that encode the tribal knowledge only senior team members would otherwise pass along verbally, such as:
- Which layout primitives and pre-built components to use
- Which directory new components should be placed in
- Naming and export patterns
- What content must never be hardcoded
- How to connect to the Design Token / styling system
- Project-specific architectural habits

Once saved, these rules will automatically apply to every subsequent Figma implementation task, reducing the need for repeated prompts.

Write rules to the correct files for each Agent¶

The Skill explicitly supports three target files:

If you are unsure about the current environment, the Skill will first check for existing rule files in the repository, or ask you directly for clarification.

Define a complete Figma MCP implementation workflow¶

The generated rules don’t just cover “where to put components”—they also formalize a mandatory implementation sequence (the Skill requires you cannot skip steps), with core steps including:
1. First use get_design_context to pull the structured representation of the target node
2. If the output is too large or truncated, first use get_metadata to view the node map, then fetch additional content as needed
3. Use get_screenshot to get visual reference
4. Once you have both the context and screenshot, download assets and start writing code
5. Translate the common MCP React + Tailwind output into your project’s conventions, styling, and framework
6. Perform a 1:1 visual and behavioral check against the Figma design before marking the task complete

It also emphasizes that MCP output is a representation of design and behavior, not the final code style; colors, spacing, and fonts must map to project tokens; assets should优先 use the localhost sources returned by the MCP, rather than installing additional icon packages or creating custom placeholder images.

Installation and Activation¶

This Skill uses the standard SKILL.md format, and can be used in tools that support the Agent Skills standard. Discovery directories vary by tool, as explained below per official documentation.

Codex CLI (openai/skills curated directory)¶

The openai/skills README states that Skills under the .curated directory can be installed by name using the built-in $skill-installer, for example:

$skill-installer figma-create-design-system-rules

You can also directly provide the GitHub directory URL. After installation, you will need to restart Codex to load the new Skill.

Note: The repository README has marked this path as deprecated, and points to openai/plugins as the future entry point for plugin/Skill examples. This article uses the currently accessible curated path and the original SKILL.md text as the reference.

Cursor¶

Cursor automatically discovers project-level or user-level Skill directories, which commonly include:
- Project-level: .cursor/skills/, .agents/skills/
- User global: ~/.cursor/skills/, ~/.agents/skills/
- Compatible loading paths: .claude/skills/, .codex/skills/, etc.

In practice, you can place this Skill directory (at minimum containing SKILL.md) into one of the above paths; alternatively, you can import the repository link via Remote Rule (GitHub) in Cursor’s Customize → Rules menu. Once enabled, you can trigger the Skill by saying “generate design system rules for my project” naturally in an Agent conversation, or manually select the Skill name via the / command menu.

Claude Code¶

Place the Skill into the skills directory that Claude Code scans (for example, .claude/skills/figma-create-design-system-rules/SKILL.md inside the project). The Agent will automatically match it based on the description, or you can explicitly request to create design system rules in the conversation.

Shared Prerequisite: Connect the Figma MCP¶

Regardless of which Agent you use, this Skill requires the Figma MCP Server to be connected. The rule generation phase will call the create_design_system_rules tool (referred to as a tool in the Skill; the official Figma “Tools and prompts” documentation categorizes it under MCP Prompt, and notes that not all clients support Prompts). If your client does not support this Prompt/tool, you can fall back to the example prompts in the Figma documentation, have the Agent manually analyze the codebase and draft the rules, then save them using the process below.

Typical Usage¶

The official workflow consists of five sequential steps:

1. Call create_design_system_rules to get the template¶

Pass the project language and framework to the Figma MCP, for example:
- clientLanguages: "typescript,javascript"
- clientFrameworks: "react" / "vue" / "svelte" / "angular" / "unknown"

The returned content is the base prompts and template for writing the rules, and the subsequent structure should follow the template.

2. Analyze the codebase¶

Before drafting the rules, take stock of the current state, covering at minimum:
- Where the component directory is, whether there is a standalone design system package, and whether organization is by feature or type
- Styling solution (Tailwind, CSS Modules, styled-components, etc.) and the location of Token definitions
- Naming conventions, props, and composition patterns
- Architectural choices such as state management, routing, and path aliases

3. Generate project-specific rules¶

Fill in the specific paths and conventions based on your analysis. The Skill recommends including at minimum these sections:

Component rules example:

- 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 example:

- 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

Cursor rule file frontmatter example:

---
description: Rules for implementing Figma designs using the Figma MCP server. Covers component organization, styling conventions, design tokens, asset handling, and the required Figma-to-code workflow.
globs: "src/components/**"
alwaysApply: false
---

[Paste the generated rule body here]

Update the globs field to match your actual Figma code implementation directory, for example "src/**/*.tsx", or ["src/components/**", "src/pages/**"].

4. Save to the corresponding Agent rule file¶

Write to CLAUDE.md, AGENTS.md, or .cursor/rules/figma-design-system.mdc as outlined in the previous table. After saving, the Agent will automatically load the rules for subsequent Figma implementation tasks.

5. Validate and iterate with a small component¶

The official recommendation is: first test with a simple component (such as a Button) to confirm the implementation works → check if the Agent followed the rules → refine any failed rules to be more specific → align with your team → update the rules regularly as the project evolves.

Example conversation triggers (from the Skill examples):
- “Create design system rules for my React project”
- “Set up Figma rules for my Vue app”
- “Generate rules for our design system library”

Applicable Scenarios and Notes¶

Best for:
- Teams that already have or are building a component library / Design Token system, and want to eliminate inconsistent Figma-to-code implementations
- Frontend teams with multiple Agents sharing the same setup, who need to unify paths, naming, and styling sources
- Teams with design system packages in a monorepo, who need to include package paths, Storybook, and testing conventions in the rules

Notes:
1. No Figma MCP means the official workflow cannot run. Complete MCP connection first before generating rules.
2. Rules must be specific and actionable. The Skill explicitly rejects vague statements: instead of writing “use the design system”, write “buttons must always use src/components/ui/Button.tsx, and the variant prop can only be 'primary' | 'secondary' | 'ghost'”. Use the IMPORTANT: prefix for critical constraints to raise their priority.
3. More rules are not always better. Excessively long rules will bloat the context and increase latency; the official recommendation is to first focus on the 20% of rules that solve 80% of consistency issues, then add more incrementally.
4. Rules will become outdated. Update the rules when architecture or Token locations change, and track them with version control; Codex’s AGENTS.md also has a 32 KiB combined size limit, so pay attention to file size when appending content.
5. Materials are in Beta. The license states that Figma may modify, suspend, or discontinue the relevant materials at any time, so you should retain manual reviews in production workflows.
6. MCP output defaults to React + Tailwind. You must explicitly write rules in your configuration to map to Vue, CSS Modules, custom Tokens, etc., otherwise the Agent may default to “copying Tailwind utility classes”.

Summary¶

figma-create-design-system-rules solves the most frustrating aspect of frontend collaboration: turning design systems and repository conventions from verbal team knowledge into rule files that the Agent will load every time it implements Figma designs. It depends on the Figma MCP, outputs to CLAUDE.md / AGENTS.md / .cursor/rules/figma-design-system.mdc, and validates its effectiveness with small-scale implementation tests.

Official links:
- Skill directory: https://github.com/openai/skills/tree/main/skills/.curated/figma-create-design-system-rules
- Figma MCP Tools and Prompts documentation: https://developers.figma.com/docs/figma-mcp-server/tools-and-prompts/
- Custom Rules Guide: https://developers.figma.com/docs/figma-mcp-server/add-custom-rules/