Back to Details

create-design-system-rules

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
本功能可帮助你生成适配项目特定需求的定制化设计系统规则。这些规则会指导Claude在实现Figma设计时输出一致、高质量的代码，确保自动遵循你团队的约定、组件模式和架构决策。

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.
设计系统规则是项目级别的指导规范，编码了代码库的「隐性知识」——也就是资深开发者了解、会传递给新团队成员的专业经验：
  • 应该使用哪些布局原语和组件
  • 组件文件应该存放在什么位置
  • 组件应该如何命名和结构设计
  • 哪些内容绝对不能硬编码
  • 如何处理设计令牌和样式
  • 项目特有的架构模式
规则定义完成后，能大幅减少重复提示，确保所有Figma实现任务的输出一致性。

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)
  • 必须连接并可访问Figma MCP服务器
  • 有权限访问项目代码库用于分析
  • 了解团队的组件约定（或愿意共同制定相关约定）

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"
当出现以下场景时使用本功能：
  • 启动一个会用到Figma设计的新项目
  • 让Claude适配已有既定模式的存量项目
  • 为整个团队标准化Figma转代码工作流
  • 更新或优化现有设计系统约定
  • 用户明确提出需求：「创建设计系统规则」、「设置Figma开发指南」、「为我的项目定制规则」

Required Workflow

必备工作流

Follow these steps in order. Do not skip steps.
请严格按顺序执行以下步骤，不要跳过。

Step 1: Run the Create Design System Rules Tool

步骤1：运行创建设计系统规则工具

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.
调用Figma MCP服务器的
create_design_system_rules
工具获取基础提示词和模板。
参数：
  • clientLanguages
    ：项目使用的语言，用英文逗号分隔（例如："typescript,javascript", "python", "javascript"）
  • clientFrameworks
    ：项目使用的框架（例如："react", "vue", "svelte", "angular", "unknown"）
该工具会返回设计系统规则的创建指导和模板。请按照工具返回的模板格式构建你的设计系统规则。

Step 2: Analyze the Codebase

步骤2：分析代码库

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?
在最终确定规则前，先分析项目了解现有模式：
组件组织方式：
  • UI组件存放在哪里？（例如：
    src/components/
    、
    app/ui/
    、
    lib/components/
    ）
  • 是否有专门的设计系统目录？
  • 组件是如何组织的？（按功能、按类型、扁平结构）
样式方案：
  • 使用什么CSS框架或方案？（Tailwind、CSS Modules、styled-components等）
  • 设计令牌在哪里定义？（CSS变量、主题文件、配置文件）
  • 是否已有现成的颜色、排版、间距令牌？
组件模式：
  • 使用什么命名约定？（PascalCase、kebab-case、前缀）
  • 组件props通常是如何结构设计的？
  • 是否有通用的组合模式？
架构决策：
  • 状态管理是如何处理的？
  • 使用什么路由系统？
  • 是否有特定的导入模式或路径别名？

Step 3: Generate Project-Specific Rules

步骤3：生成项目专属规则

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

Figma MCP集成规则

markdown
undefined
markdown
undefined

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

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

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

Asset Handling Rules

资源处理规则

markdown
undefined
markdown
undefined

Asset Handling

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]
undefined
  • 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]
undefined

Project-Specific Conventions

项目专属约定

markdown
undefined
markdown
undefined

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]
undefined
  • [Add any unique architectural patterns]
  • [Add any special import requirements]
  • [Add any testing requirements]
  • [Add any accessibility standards]
  • [Add any performance considerations]
undefined

Step 4: Save Rules to CLAUDE.md

步骤4：将规则保存到CLAUDE.md

Guide the user to save the generated rules to the 
CLAUDE.md
file in their project root:
markdown
undefined
引导用户将生成的规则保存到项目根目录的
CLAUDE.md
文件中：
markdown
undefined

MCP Servers

MCP Servers

Figma MCP Server Rules

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.
[Paste generated rules here]

保存后，规则会被Claude Code自动加载，并应用到所有Figma实现任务中。

Step 5: Validate and Iterate

步骤5：验证和迭代

After creating rules:
  1. Test with a simple Figma component implementation
  2. Verify Claude follows the rules correctly
  3. Refine any rules that aren't working as expected
  4. Share with team members for feedback
  5. Update rules as the project evolves
创建规则后：
  1. 用一个简单的Figma组件实现测试规则
  2. 验证Claude是否正确遵循规则
  3. 优化所有不符合预期的规则
  4. 分享给团队成员收集反馈
  5. 随着项目迭代更新规则

Rule Categories and Examples

规则分类和示例

Essential Rules (Always Include)

必备规则（始终包含）

Component Discovery:
markdown
- 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:
markdown
- 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:
markdown
- Use Tailwind utility classes for styling
- Custom styles go in component-level CSS modules
- Theme customization is in `tailwind.config.js`
组件查找规则：
markdown
- UI components are located in `src/components/ui/`
- Feature components are in `src/components/features/`
- Layout primitives are in `src/components/layout/`
设计令牌使用规则：
markdown
- 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.
样式方案规则：
markdown
- 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:
markdown
- 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:
markdown
- Use path aliases: `@/components`, `@/styles`, `@/utils`
- Group imports: React, third-party, internal, types
- No relative imports beyond parent directory
Code Quality:
markdown
- Add JSDoc comments for exported components
- Include PropTypes or TypeScript types for all props
- Extract magic numbers to named constants
组件模式规则：
markdown
- 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
导入约定规则：
markdown
- Use path aliases: `@/components`, `@/styles`, `@/utils`
- Group imports: React, third-party, internal, types
- No relative imports beyond parent directory
代码质量规则：
markdown
- 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:
markdown
- All interactive elements must have aria-labels
- Color contrast must meet WCAG AA standards
- Keyboard navigation required for all interactions
Performance:
markdown
- 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:
markdown
- Include unit tests for new components in `__tests__/` directory
- Use Testing Library queries (getByRole, getByLabelText)
- Test all interactive states and variants
可访问性规则：
markdown
- All interactive elements must have aria-labels
- Color contrast must meet WCAG AA standards
- Keyboard navigation required for all interactions
性能规则：
markdown
- 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
测试规则：
markdown
- 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

示例1：React + Tailwind项目

User says: "Create design system rules for my React project"
Actions:
  1. Run 
    create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="react")
  2. Analyze codebase structure
  3. Generate rules:
markdown
undefined
用户说：「为我的React项目创建设计系统规则」
操作：
  1. 运行
    create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="react")
  2. 分析代码库结构
  3. 生成规则：
markdown
undefined

Figma MCP Integration Rules

Figma MCP Integration Rules

Component Organization

Component Organization

  • UI components are in 
    src/components/ui/
  • Page components are in 
    src/app/
  • Use Tailwind for styling
  • UI components are in 
    src/components/ui/
  • Page components are in 
    src/app/
  • Use Tailwind for styling

Figma Implementation Flow

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

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

Asset Rules

  • IMPORTANT: Use localhost sources from Figma MCP server directly
  • Store static assets in 
    public/assets/
  • DO NOT install new icon libraries

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

**Result:** Claude now consistently follows the project's conventions when implementing Figma designs.
  • IMPORTANT: Use localhost sources from Figma MCP server directly
  • Store static assets in 
    public/assets/
  • DO NOT install new icon libraries

4. 保存到项目根目录的`CLAUDE.md`文件
5. 用一个简单的按钮实现测试

**结果：** 现在Claude在实现Figma设计时会始终遵循项目约定。

Example 2: Vue + Custom CSS Project

示例2：Vue + 自定义CSS项目

User says: "Set up Figma rules for my Vue app"
Actions:
  1. Run 
    create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="vue")
  2. Discover that project uses CSS modules and a custom design token system
  3. Generate rules:
markdown
undefined
用户说：「为我的Vue应用设置Figma规则」
操作：
  1. 运行
    create_design_system_rules(clientLanguages="typescript,javascript", clientFrameworks="vue")
  2. 发现项目使用CSS Modules和自定义设计令牌系统
  3. 生成规则：
markdown
undefined

Figma MCP Integration Rules

Figma MCP Integration Rules

Component Organization

Component Organization

  • Components are in 
    src/components/
  • Composables are in 
    src/composables/
  • Vue SFC structure: <script setup>, <template>, <style scoped>
  • Components are in 
    src/components/
  • Composables are in 
    src/composables/
  • Vue SFC structure: <script setup>, <template>, <style scoped>

Design Tokens

Design Tokens

  • IMPORTANT: All colors defined in 
    src/styles/tokens.css
    as CSS variables
  • Use 
    var(--color-primary)
    , 
    var(--color-secondary)
    , etc.
  • Spacing: 
    var(--space-xs)
    through 
    var(--space-xl)
  • Typography: 
    var(--text-sm)
    through 
    var(--text-2xl)
  • IMPORTANT: All colors defined in 
    src/styles/tokens.css
    as CSS variables
  • Use 
    var(--color-primary)
    , 
    var(--color-secondary)
    , etc.
  • Spacing: 
    var(--space-xs)
    through 
    var(--space-xl)
  • Typography: 
    var(--text-sm)
    through 
    var(--text-2xl)

Figma Implementation Flow

Figma Implementation Flow

  1. Run get_design_context and get_screenshot
  2. Translate React output to Vue 3 Composition API
  3. Map Figma colors to CSS variables in 
    src/styles/tokens.css
  4. Use CSS Modules for component styles
  5. Check for existing components in 
    src/components/
    before creating new ones
  1. Run get_design_context and get_screenshot
  2. Translate React output to Vue 3 Composition API
  3. Map Figma colors to CSS variables in 
    src/styles/tokens.css
  4. Use CSS Modules for component styles
  5. Check for existing components in 
    src/components/
    before creating new ones

Styling Rules

Styling Rules

  • Use CSS Modules (
    .module.css
    files)
  • IMPORTANT: Reference design tokens, never hardcode values
  • Scoped styles with CSS modules

4. Save to `CLAUDE.md` in project root
5. Validate with a card component

**Result:** Claude now correctly translates Figma designs to Vue components using the project's design token system.
  • Use CSS Modules (
    .module.css
    files)
  • IMPORTANT: Reference design tokens, never hardcode values
  • Scoped styles with CSS modules

4. 保存到项目根目录的`CLAUDE.md`文件
5. 用一个卡片组件验证

**结果：** 现在Claude可以使用项目的设计令牌系统，正确将Figma设计转换为Vue组件。

Example 3: Design System Team

示例3：设计系统团队

User says: "Generate rules for our design system library"
Actions:
  1. Run 
    create_design_system_rules(clientLanguages="typescript", clientFrameworks="react")
  2. Analyze the monorepo structure with design system package
  3. Generate comprehensive rules:
markdown
undefined
用户说：「为我们的设计系统库生成规则」
操作：
  1. 运行
    create_design_system_rules(clientLanguages="typescript", clientFrameworks="react")
  2. 分析包含设计系统包的monorepo结构
  3. 生成完整规则：
markdown
undefined

Design System Rules

Design System Rules

Repository Structure

Repository Structure

  • Design system components: 
    packages/design-system/src/components/
  • Documentation: 
    packages/docs/
  • Design tokens: 
    packages/tokens/src/
  • Design system components: 
    packages/design-system/src/components/
  • Documentation: 
    packages/docs/
  • Design tokens: 
    packages/tokens/src/

Component Development

Component Development

  • IMPORTANT: All components must be in 
    packages/design-system/src/components/
  • Component file structure: 
    ComponentName/index.tsx
    , 
    ComponentName.stories.tsx
    , 
    ComponentName.test.tsx
  • Export all components from 
    packages/design-system/src/index.ts
  • IMPORTANT: All components must be in 
    packages/design-system/src/components/
  • Component file structure: 
    ComponentName/index.tsx
    , 
    ComponentName.stories.tsx
    , 
    ComponentName.test.tsx
  • Export all components from 
    packages/design-system/src/index.ts

Design Tokens

Design Tokens

  • Colors: 
    packages/tokens/src/colors.ts
  • Typography: 
    packages/tokens/src/typography.ts
  • Spacing: 
    packages/tokens/src/spacing.ts
  • IMPORTANT: Never hardcode values - import from tokens package
  • Colors: 
    packages/tokens/src/colors.ts
  • Typography: 
    packages/tokens/src/typography.ts
  • Spacing: 
    packages/tokens/src/spacing.ts
  • IMPORTANT: Never hardcode values - import from tokens package

Documentation Requirements

Documentation Requirements

  • Add Storybook story for every component
  • Include JSDoc with @example
  • Document all props with descriptions
  • Add accessibility notes
  • Add Storybook story for every component
  • Include JSDoc with @example
  • Document all props with descriptions
  • Add accessibility notes

Figma Integration

Figma Integration

  1. Get design context and screenshot from Figma
  2. Map Figma tokens to design system tokens
  3. Create or extend component in design system package
  4. Add Storybook stories showing all variants
  5. Validate against Figma screenshot
  6. Update documentation

4. Save to `CLAUDE.md` and share with team
5. Add to team documentation

**Result:** Entire team follows consistent patterns when adding components from Figma to the design system.
  1. Get design context and screenshot from Figma
  2. Map Figma tokens to design system tokens
  3. Create or extend component in design system package
  4. Add Storybook stories showing all variants
  5. Validate against Figma screenshot
  6. Update documentation

4. 保存到`CLAUDE.md`并分享给团队
5. 添加到团队文档中

**结果：** 整个团队在将Figma组件添加到设计系统时，都会遵循一致的模式。

Best Practices

最佳实践

Start Simple, Iterate

从简单开始，逐步迭代

Don't try to capture every rule upfront. Start with the most important conventions and add rules as you encounter inconsistencies.
不要尝试一开始就覆盖所有规则。先从最重要的约定开始，遇到不一致的情况再补充规则。

Be Specific

规则要明确具体

Instead of: "Use the design system" Write: "Always use Button components from 
src/components/ui/Button.tsx
with variant prop ('primary' | 'secondary' | 'ghost')"
不要写：「使用设计系统」 而要写：「始终使用
src/components/ui/Button.tsx
中的Button组件，搭配variant prop ('primary' | 'secondary' | 'ghost')」

Make Rules Actionable

让规则可落地执行

Each rule should tell Claude exactly what to do, not just what to avoid.
Good: "Colors are defined in 
src/theme/colors.ts
- import and use these constants" Bad: "Don't hardcode colors"
每条规则都应该明确告诉Claude应该做什么，而不只是禁止做什么。
正面示例：「颜色定义在
src/theme/colors.ts
中，请导入并使用这些常量」 负面示例：「不要硬编码颜色」

Use IMPORTANT for Critical Rules

关键规则使用IMPORTANT前缀

Prefix rules that must never be violated with "IMPORTANT:" to ensure Claude prioritizes them.
markdown
- IMPORTANT: Never expose API keys in client-side code
- IMPORTANT: Always sanitize user input before rendering
给绝对不能违反的规则加上「IMPORTANT:」前缀，确保Claude会优先处理这些规则。
markdown
- IMPORTANT: Never expose API keys in client-side code
- IMPORTANT: Always sanitize user input before rendering

Document the Why

说明规则的原因

When rules seem arbitrary, explain the reasoning:
markdown
- Place all data-fetching in server components (reduces client bundle size and improves performance)
- Use absolute imports with `@/` alias (makes refactoring easier and prevents broken relative paths)
如果规则看起来比较主观，请解释背后的原因：
markdown
- Place all data-fetching in server components (reduces client bundle size and improves performance)
- Use absolute imports with `@/` alias (makes refactoring easier and prevents broken relative paths)

Common Issues and Solutions

常见问题和解决方案

Issue: Claude isn't following the rules

问题：Claude没有遵循规则

Cause: Rules may be too vague or not properly loaded into the IDE/MCP client.
Solution:
  • Make rules more specific and actionable
  • Verify rules are saved in the correct configuration file
  • Restart your IDE or MCP client to reload rules
  • Add "IMPORTANT:" prefix to critical rules
原因： 规则可能太模糊，或者没有正确加载到IDE/MCP客户端中。
解决方案：
  • 让规则更明确、更可落地
  • 验证规则是否保存在正确的配置文件中
  • 重启IDE或MCP客户端重新加载规则
  • 给关键规则加上「IMPORTANT:」前缀

Issue: Rules conflict with each other

问题：规则之间存在冲突

Cause: Contradictory or overlapping rules.
Solution:
  • Review all rules for conflicts
  • Establish a clear priority hierarchy
  • Remove redundant rules
  • Consolidate related rules into single, clear statements
原因： 规则相互矛盾或重叠。
解决方案：
  • 检查所有规则是否存在冲突
  • 建立清晰的优先级层级
  • 删除冗余规则
  • 将相关规则合并为单一、清晰的表述

Issue: Too many rules make Claude slow

问题：规则太多导致Claude响应变慢

Cause: Excessive rules increase context size and processing time.
Solution:
  • Focus on the 20% of rules that solve 80% of consistency issues
  • Remove overly specific rules that rarely apply
  • Combine related rules
  • Use progressive disclosure (basic rules first, advanced rules in linked files)
原因： 过多的规则会增加上下文大小和处理时间。
解决方案：
  • 聚焦于能解决80%一致性问题的20%核心规则
  • 删除很少适用的过于具体的规则
  • 合并相关规则
  • 使用渐进式披露（先放基础规则，高级规则放在链接的文件中）

Issue: Rules become outdated as project evolves

问题：随着项目迭代，规则过时了

Cause: Codebase changes but rules don't.
Solution:
  • Schedule periodic rule reviews (monthly or quarterly)
  • Update rules when architectural decisions change
  • Version control your rule files
  • Document rule changes in commit messages
原因： 代码库变了但规则没有更新。
解决方案：
  • 定期安排规则评审（每月或每季度）
  • 架构决策变更时同步更新规则
  • 将规则文件纳入版本控制
  • 在提交信息中说明规则变更内容

Understanding Design System Rules

设计系统规则的价值

Design system rules transform how Claude works with your Figma designs:
Before rules:
  • Claude makes assumptions about component structure
  • Inconsistent styling approaches across implementations
  • Hardcoded values that don't match design tokens
  • Components created in random locations
  • Repetitive explanations of project conventions
After rules:
  • Claude automatically follows your conventions
  • Consistent component structure and styling
  • Proper use of design tokens from the start
  • Components organized correctly
  • Zero repetitive prompting
The time invested in creating good rules pays off exponentially across every Figma implementation task.
设计系统规则会彻底改变Claude处理你的Figma设计的方式：
使用规则前：
  • Claude会对组件结构做假设
  • 不同实现的样式方案不一致
  • 硬编码的值不符合设计令牌要求
  • 组件被创建在随机位置
  • 需要反复解释项目约定
使用规则后：
  • Claude自动遵循你的约定
  • 组件结构和样式保持一致
  • 从一开始就正确使用设计令牌
  • 组件组织规范
  • 不需要再重复提示
在创建优质规则上投入的时间，会在每一次Figma实现任务中获得指数级的回报。

Additional Resources

更多资源