Use Figma MCP in Claude Code

Start with a read-only design handoff, not a broad Figma bridge. For Figma MCP in Claude Code, the working pattern is to let Claude Code read selected design context through MCP, ask for an implementation plan, then make code changes behind the same review rules as any other pull request. In a Claude Code workshop, I would teach this as a team convention before I teach the connection details, because design context can help and mislead in the same session.

A Figma MCP Claude Code workflow should end with reviewable code, not a pasted design guess. Figma is the design source, Claude Code is the coding surface, and your team still owns the interpretation between them.

Keep Figma access narrow

Give Claude Code the smallest Figma access that supports the task. In practice, that usually means read access to the relevant file, frame, or component metadata, not permission to change the design source or publish tokens.

The exact permission knobs depend on the MCP server and your admin setup, so write down what the server may read before the team starts using it. If the ownership question is still open, settle that first with a clear server boundary such as the one in Set a Claude Code MCP Server Boundary.

A normal workflow example is a React app with Storybook and shared design tokens. Claude Code can inspect the requested Figma frame, compare it with existing Button, Card, and spacing tokens, then implement the screen using the repo components rather than inventing one-off CSS.

Make design intent explicit before code changes

Ask Claude Code for a short design contract before it edits files. The contract should name the Figma frame, the target route or component, the existing components it plans to reuse, and the assumptions it is making about states that are not visible in the design.

This belongs with your Team conventions, not hidden in a private prompt. A small supporting note in CLAUDE.md can help if the rule is durable, for example “prefer existing design system components before adding layout CSS,” but the Figma-specific decision should live in the workflow people actually run.

This is also where I connect it to the Review step in our methodology. The reviewer should not have to replay the chat to understand why a component was chosen.

Run the Figma-to-code procedure

Use a fixed procedure so the agent does not jump from a design URL straight into edits. This is the part of the workflow I would make repeatable for Claude Code teams.

1. Paste the Figma link, selected frame name, and target repo path into Claude Code.
2. Ask for a plan only: components to reuse, files likely to change, missing states, and risks.
3. Have Claude Code inspect the relevant repo components, stories, and tokens before editing.
4. Approve or correct the plan, then let it implement the smallest useful slice.
5. Run the normal checks for the repo, such as typecheck, lint, unit tests, or Storybook validation.
6. Ask Claude Code for a review note that links the design input to the code changes and lists assumptions.
7. Review the result as product code, not as a design export.

This procedure is deliberately slow at the start. It prevents the common failure where Claude Code copies visible layout details while missing component contracts, responsive behavior, empty states, or accessibility requirements.

Paste this slash-command workflow

Use a project slash command when several people will repeat the same Figma handoff. Keep it short enough that developers will read it.

# /figma-implement

Use this command to implement one UI change from a Figma frame through MCP.

Required inputs:
- Figma file or frame link:
- Target route, component, or package:
- Expected user state:
- Checks to run:

Rules:
- Read Figma context only. Do not write back to Figma.
- Reuse existing repo components and design tokens before adding new styles.
- Do not edit unrelated files to make the design fit.
- Stop and ask when the design omits loading, empty, error, disabled, or mobile states.

Workflow:
1. Read the Figma frame and summarize the visible design intent.
2. Inspect nearby repo components, stories, tokens, and tests.
3. Produce a plan before editing files.
4. After approval, implement the smallest vertical slice.
5. Run the requested checks.
6. Return a review note with:
   - Figma frame used
   - Files changed
   - Existing components reused
   - Assumptions made
   - Checks run and results

Treat this as a starting command, not policy by itself. The server permission boundary and repo review rules still matter more than the wording of the command.

Check what Figma cannot tell Claude Code

Figma can show structure, spacing, labels, and visual hierarchy. It often cannot tell Claude Code the backend state model, the analytics requirement, the accessibility intent, or which responsive breakpoint matters most.

That limit is not a reason to avoid Figma MCP. It is a reason to make Claude Code name missing information before it writes code.

The best review comments on these changes are specific. Ask whether the implementation reused the design system, whether the missing states were handled, whether the generated CSS is local and necessary, and whether the checks prove anything meaningful.

Further reading

• Claude Code docs
• Claude Code skills
• MCP specification

Try it on one design handoff

Pick one small UI change, add the slash command, and run it with read-only Figma access before widening permissions. If you want a coached version, hands-on Claude Code training runs this as a design-to-code exercise with review evidence.