SECTION 01
Three Rules That Dramatically Improve Figma Implementation Accuracy
When generating code from Figma designs with Claude Code, inconsistent output is a common frustration. The same screen can produce different class names and component structures each time you run it.
The root cause isn't insufficient input data — it's that the AI doesn't know your project's conventions. Manually specifying them in every prompt is unrealistic and leads to gaps and inconsistencies.
The solution is defining three key pieces of information in CLAUDE.md, the rules file that Claude Code automatically reads for each project:
- Design tokens: Color values, spacing scales, and font size definitions
- Component splitting rules: Granularity standards and naming conventions
- Tech stack constraints: Specifying Tailwind CSS, React, Next.js, or other technologies
Without rules, the AI defaults to generic class names and inline styles. With these three definitions in place, the output aligns with your existing codebase. The Before/After difference is immediately visible, even for the same Figma screen.
SECTION 02
How to Pass Design Data from Figma MCP to Claude Code
Describing a design in natural language is remarkably inefficient. Telling the AI "there's a fixed header with a sidebar" leads to endless rounds of correction. The key is to provide a visual reference before giving instructions.
Figma MCP (Model Context Protocol) lets you feed Figma design data directly into Claude Code. Setup involves adding the Figma MCP server configuration to Claude Code's settings.json and generating an access token on the Figma side.
The method you use to pass data creates clear differences in accuracy. There are three main approaches:
- Screenshot only: Quick but vague on layout structure and exact color codes
- Dev Mode properties included: CSS values and spacing are conveyed accurately, improving output precision
- Layout structure text supplements added: Communicates component hierarchy and state changes
In practice, screenshots alone work for simple UIs like basic card layouts. But for complex interfaces with responsive behavior or hover states, text supplements become essential for maintaining accuracy.
More input data means better precision, but balancing preparation cost matters. When your rules file already defines the design system, even a screenshot with minimal notes can produce surprisingly accurate output.
SECTION 03
CLAUDE.md Rules Template for Figma Implementation
The overall structure of a rules file works best when divided into three blocks: design system, component architecture, and output format. This structure gives the AI clear guidance when processing Figma data.
The design system block should contain color palettes, spacing multiplier rules, and font size scales. For example, specifying CSS variable names for primary colors and a base spacing unit (like 4px multiples) ensures the generated code consistently references the same tokens.
The component architecture block defines splitting criteria and naming conventions like these:
- Whether to use Atomic Design granularity or page-level organization
- File naming conventions for components (PascalCase, kebab-case, etc.)
- Props typing strategy (TypeScript interface vs. type alias)
The output format block specifies tech stack constraints: "Use Tailwind CSS utility classes only," "No custom CSS allowed," "Use Next.js App Router." When this section is vague, the AI invents its own CSS architecture every time.
A well-structured template is reusable across projects. Keep a common base and swap out project-specific colors and component names — this approach scales well.
SECTION 04
Tailwind CSS Rules: Let AI Generate the Entire Class Design
For AI-first coding workflows, Tailwind CSS is the most rational choice. Since styles are applied directly via utility classes without separate CSS files, the AI can generate design and code in a single pass.
The most impactful Tailwind-specific rules are custom color and spacing definitions. Writing the tokens from your tailwind.config.js into CLAUDE.md ensures the AI uses your project-specific utility classes correctly.
Key items to include in your Tailwind rules:
- Project-specific class names like
bg-primaryandtext-accentwith usage descriptions - Responsive breakpoint guidelines (when to use
sm:,md:,lg:) @applyusage policy and class organization conventions within components
When passing Figma screenshots or screen data, Tailwind lets the AI generate the complete class design alongside the markup. Without separate CSS files to manage, the generated code stays more consistent.
Defining naming conventions in rules has the added benefit of unifying code appearance across the team. Reviewing AI-generated code becomes straightforward when there are clear rules to check against.
SECTION 05
React and Next.js Rules: Component Granularity and File Structure
For React and Next.js projects, component granularity and file placement are the core of your rules. Without guidance, the AI might dump everything into one file or split things excessively — neither is consistent.
The minimum rules to define are directory structure and component splitting criteria. For example: "Generic UI components go in components/ui/" and "Feature-specific components go in features/."
For Next.js-specific rules, specifying these items stabilizes the output:
- Server Component vs. Client Component boundaries (when to add
'use client') - App Router conventions (usage of page.tsx, layout.tsx)
- Data fetching strategy (Server Actions vs. API Routes)
For plain HTML/CSS projects, the focus shifts to BEM naming conventions and CSS variable definitions. The AI tends to invent its own class names by default, so specifying naming patterns alone dramatically improves output consistency.
SECTION 06
From .cursorrules to CLAUDE.md — What Rules Design Taught Me
The concept of rules files originated with .cursorrules in Cursor. Early on with Cursor, coding accuracy was frustratingly low. Writing project conventions into every prompt was tedious and error-prone.
Discovering .cursorrules (Cursor's auto-loaded project-specific rules file) was the turning point — realizing that writing conventions once meant never repeating them changed everything. This rules-based approach significantly boosted the efficiency of editor-integrated AI.
After switching to Claude Code, the file became CLAUDE.md, but the core idea is identical. Regardless of which tool you use, defining rules for AI to follow is what stabilizes output quality.
There is, however, one key difference. Cursor emphasizes interactive, conversational corrections, while Claude Code is designed to operate more autonomously. This changes what you need to write in your rules.
- Rules for interactive workflows: Focus mainly on output format specifications
- Rules for autonomous AI workflows: Must include decision criteria and prohibited patterns
- In Claude Code, defining judgment frameworks ("when X happens, do Y") is especially effective
This realization led to writing rules at the start of every project as a habit. Taking time to set up CLAUDE.md before writing any code dramatically reduces the number of correction rounds later.
SECTION 07
Practical Steps for Adding Figma Screens to Existing Projects
When implementing Figma screens with Claude Code, generating an entire page from scratch is usually a mistake for existing codebases. Wholesale generation creates code that conflicts with established components and design patterns.
Through trial and error, the approach that works best is having the AI create an implementation plan before writing any code. Pass requirements as bullet points, have the AI outline which files change and how, then review before proceeding.
This workflow is especially effective for incremental implementation into existing codebases. The concrete steps look like this:
- Pass the Figma mockup (screenshot or Dev Mode data) to Claude Code
- Instruct: "Create an implementation plan using existing ○○ components"
- Review the generated plan before giving the go-ahead to implement
A critical judgment here is knowing when to prioritize maintainability over design fidelity. Perfectly matching Figma's visual output sometimes requires deviating from your existing design system. In those cases, suggesting minor design adjustments yields better long-term results.
The order of operations also matters: passing the mockup first, then applying rules as constraints. The AI produces more accurate code when it sees the visual target before applying rules, rather than reading rules first and imagining the screen.
SECTION 08
Vague Instructions Break Code, Planning Protects It
Vague instructions like "build a registration feature" cause the AI to misread context and damage the codebase. After encountering this problem repeatedly, the planning-first workflow became non-negotiable.
Including the planning flow in CLAUDE.md means the AI automatically follows a plan → review → implement sequence without being told each time. For Figma screen implementation, this means having the AI identify which existing components to reuse before writing any code.
The implementation plan should include these specific items:
- List of files to modify with a summary of changes for each
- Names and props type definitions for any new components
- Dependency checks against existing components
The time spent reviewing a plan is vastly shorter than fixing broken code after the fact. For complex Figma screens especially, skipping the planning step leads to significant rework.
SECTION 09
When to Use Claude Code vs. v0, Cursor, and Figma's Built-in Code Generation
Multiple tools can convert Figma designs to code, but each excels in different scenarios. Rather than committing to one tool, using them strategically based on context is more efficient.
Claude Code's greatest strength is rules-based output control and alignment with existing codebases. Because you can define project-specific rules, the generated code consistently follows your team's architecture. This advantage is most pronounced when integrating into existing projects.
Here's how the tools divide responsibilities:
- v0 (Vercel's AI UI generator): Excels at rapid prototyping. Best for quickly visualizing design ideas
- Cursor: Strong at interactive, conversational refinement. Ideal for fine-tuning styles through dialogue
- Figma's built-in code generation: Extracts CSS and layout info from Dev Mode. However, it doesn't produce implementation-ready code packages
An effective combined workflow is prototyping with v0, then production-implementing with Claude Code. Use v0 to quickly validate the visual direction, then use Claude Code with rules to produce production-quality code.
To summarize when to choose Claude Code: when you have an existing codebase and need implementation that follows team conventions. It delivers its greatest value not in greenfield generation, but in leveraging existing assets.
SECTION 10
Practical Tips to Get Started Today
Based on everything covered, here are concrete actions you can take today. Don't aim for perfect rules upfront — start with minimal definitions and feel the difference first.
The first step is to write just three design tokens in CLAUDE.md: your primary color, base spacing value, and main font family. These three definitions alone create a noticeable improvement in output consistency.
Then gradually expand your rules following this progression:
- Day one: Write only color, spacing, and font design tokens
- After one week: Add component naming conventions and file placement rules
- As you build: Append rules whenever you notice output inconsistencies
Rules aren't a one-time setup — they're living documents that grow with your project. When you notice the AI's output drifting on a specific point, adding a rule for it right then starts a continuous improvement cycle that steadily increases implementation accuracy.
Figma-to-code implementation is an area where rules quality directly determines output quality. Investing the initial effort to set up CLAUDE.md pays dividends across your entire implementation workflow. Start with your current project today.
