Claude Code can help a designer turn an approved Figma frame into working interface code. The difficult part is not producing the first screen. It is fitting that screen into an existing repository without replacing real components, losing important states, or hiding problems behind a convincing preview.

Treat the pull request as the deliverable. Merge and production deployment stay in the team's normal review process. The workflow below starts with a read-only inspection, connects Figma through the official MCP server, implements a bounded change, runs the repository's actual checks, and gives a reviewer the evidence needed to assess it.

What this workflow should produce

A good result is deliberately modest:

  • a focused change on a separate branch;
  • reuse of the repository's existing components and tokens;
  • defined responsive, loading, empty, error, and interaction states;
  • passing lint, type, test, build, and visual checks that the project actually uses;
  • a reviewed diff and a pull request with test evidence and known limitations.

Claude can perform much of the mechanical work, but the person approving the change must still understand what it does. If nobody on the review path can explain the code, its data flow, or its failure modes, the change is not ready to merge.

1. Install Claude Code and sign in

Use the current Claude Code setup guide as the source of truth. Anthropic recommends the native installer. As of July 17, 2026, the documented commands are:

macOS, Linux, or WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Verify the installation:

claude --version
claude doctor

Run claude and follow the browser sign-in flow. Claude Code currently requires a Pro, Max, Team, Enterprise, or Console account; the free Claude.ai plan does not include access. Supported corporate cloud providers are another option. Inside a session, /status shows the active account and configuration.

Do not use sudo npm install -g to work around installation permissions. Anthropic warns that it can create permission and security problems. If the native installer is unsuitable, follow the documented package-manager alternatives instead.

2. Prepare the repository and its guardrails

Check the repository state

Open the existing project in a terminal and inspect it before starting an agent:

cd /path/to/project
git status --short
git branch --show-current

If the working tree already contains changes, identify who owns them. Do not discard or overwrite work you do not recognize. Create a branch according to the team's convention before implementation, and confirm that a direct push to the default branch is outside the task.

Write short project instructions

CLAUDE.md gives Claude project-specific instructions at the start of a session. Shared instructions can live in ./CLAUDE.md or ./.claude/CLAUDE.md; ./CLAUDE.local.md is for personal project notes and should be ignored by git. Run /init for a starting version, then edit it like team documentation.

For interface work, include the package manager, exact check commands, component and token paths, styling and localization conventions, repository etiquette, and actions the agent must not perform. Keep the file concise. Do not put credentials, tokens, customer records, or other sensitive data in it.

These instructions are advisory. Enforce prohibitions on git push, deployment, migrations, and secret access with permission rules, hooks, branch protection, and remote access controls.

Choose permissions and sandbox boundaries

Claude Code has several permission modes. Use plan while investigating, then move to default or acceptEdits after approving the plan. Default mode permits reads and recognized read-only commands, while prompting for edits and most write-capable actions. acceptEdits also auto-approves common in-scope filesystem commands, including rm, rmdir, mv, cp, and sed.

Auto mode can reduce approval fatigue when the boundaries are already clear. dontAsk is intended for restricted automation with tools defined in advance. Do not use --dangerously-skip-permissions on a normal workstation or valuable repository. Anthropic reserves its equivalent, bypassPermissions, for isolated containers or virtual machines and states that it offers no protection from prompt injection or unintended actions.

Open /sandbox to configure OS-level isolation for shell commands. Permissions decide whether a tool call may run; the sandbox limits what a shell command can access after it starts. By default, sandboxed shell commands may run without a separate command prompt because autoAllowBashIfSandboxed is enabled, although explicit deny rules still apply. The default sandbox primarily confines writes to the working directory, so configure denied read paths and matching permission rules for credentials and other sensitive files.

For a strict policy, enable the sandbox, set sandbox.failIfUnavailable to true, and set sandbox.allowUnsandboxedCommands to false. The first setting stops startup when isolation is unavailable; the second disables runtime retries outside the sandbox. Review any excluded commands separately. Native Windows does not support the sandbox, although WSL2 does.

3. Connect the official Figma MCP server

Figma recommends its remote MCP server for most users. In Claude Code, the preferred setup is the official plugin:

claude plugin install figma@claude-plugins-official

The manual project-scoped alternative is:

claude mcp add --transport http figma https://mcp.figma.com/mcp

Start a new Claude Code session, run /mcp, select Figma, and complete OAuth. The full sequence is maintained in Figma's remote server installation guide. The connection uses the permissions of the signed-in Figma user. Some MCP tools can create, edit, or delete canvas objects, so OAuth does not make the connection read-only. For a context-only task, require approval for write tools and use an account whose Figma access matches the task.

Provide a link to the specific frame or layer, not only the top-level file. Ask Claude for design context, a screenshot, and relevant variable definitions. If Code Connect mappings already exist, use them. If they are missing or outdated, involve the design-system owner instead of inventing substitutes.

Figma explains that its server may return a React and Tailwind representation as an intermediate format. That response is not production-ready code. It must be adapted to the repository's framework, styles, components, semantics, and behavior.

4. Explore, plan, then implement

Start Claude in read-only plan mode:

claude --permission-mode plan

Claude Code's current best-practices guide recommends separating exploration and planning from implementation. Ask it to inspect the README, package manager, scripts, UI architecture, component library, tests, and nearby implementations. Before allowing writes, review a plan that names the files to change, what remains out of scope, required states and breakpoints, measurable acceptance criteria, verification commands, and decisions that need a person.

A concrete implementation prompt is more useful than "build this design":

Implement the approved Figma frame at [frame URL] for the billing settings route. You may edit only [allowed paths]. Reuse [named components] and existing tokens; do not add a UI library. Cover loading, empty, validation, server-error, disabled, and success states at [breakpoints]. Run [repository commands] and compare screenshots at [viewports]. List any mismatch or skipped check. Stop before commit, push, or deployment.

Replace the brackets with project facts. Once the plan is approved, switch out of plan mode and implement only that scope. Stop and ask when Figma and the repository disagree about behavior, or when the change reaches authentication, payments, personal data, migrations, or infrastructure.

5. Translate design context into repository code

Follow existing patterns before introducing anything new. For every visible element, check whether the project already has the component, token, icon, utility, or content pattern. A generated button can match the screenshot and still bypass the real button component, keyboard behavior, analytics, or localization.

Make the states that Figma may not show explicit:

  • What happens during loading, empty data, validation failure, permission denial, and server error?
  • How does focus move after a modal opens or an action completes?
  • What changes at narrow widths, high zoom, and with long translated content?
  • Which controls are disabled, selected, pressed, expanded, or destructive?
  • Where does data come from, and what must never be logged or sent to a client?

Figma is evidence for visual intent, not a complete specification. Record unresolved differences in the pull request rather than silently choosing whichever source is easier to implement.

6. Verify the work, inspect the diff, and open a PR

Claude performs better when it has a pass-or-fail signal. Run the check commands defined by the repository, not a universal recipe copied from another stack. Identify the relevant lint, typecheck, unit or integration tests, build, and visual checks.

Compare screenshots at the agreed viewport sizes and exercise the whole flow. Check keyboard navigation, visible focus, accessible names, semantic controls, error messaging, contrast, zoom, and touch targets. The W3C accessibility evaluation guidance notes that automated tools cannot determine accessibility on their own; qualified human evaluation is still required.

Ask Claude to report the exact commands it ran, their outcomes, and any skipped checks. Then inspect everything that changed:

git status --short
git diff --check
git diff --stat
git diff
git diff --cached

Open every untracked file before staging it; git diff does not show its contents. Look for unrelated edits, generated files, debug logging, disabled tests, assets without usage rights, hard-coded values, environment files, tokens, and credentials. A .gitignore entry does not protect a secret that was already tracked or copied elsewhere.

The pull request should link the Figma frame and acceptance criteria, show screenshots for relevant states and viewports, list the checks and results, record human accessibility review, and state known limitations. Required status checks and a person who understands the change should remain merge gates.

7. Keep production behind a separate gate

Preview or staging is the next environment for user-flow testing, integration checks, and stakeholder review. Production changes should use the team's normal approval process, monitoring, and rollback plan.

GitHub protected branches can require pull-request reviews and status checks. GitHub environments can add required reviewers, branch restrictions, and delayed access to environment secrets. Availability of individual protection features depends on repository visibility and plan, so verify the current entitlement. Equivalent controls exist in other deployment systems.

Do not give a coding agent standing access to production secrets merely because it produced a good preview. Database migrations, authentication changes, billing, data deletion, and infrastructure edits deserve their own review and execution plan.