How to take over a design built in Figma Make and develop it with Claude Code

One app I took over from Figma Make had earth-tone color tokens (named color values that every screen is supposed to refer to) defined in one file, theme.css. Not one component file used them: 0 files referenced var(--color-*), and 35 files hardcoded the same colors directly. Changing a token changed nothing on screen. The app looked finished, and that is exactly why the problem was easy to miss.

Figma Make is Figma's AI feature that turns a prompt into a working app, not just a picture of one. Since around the turn of 2026 I have started several web apps from code that Figma Make wrote: a beauty-curation site, a gift-record app, a plush-toy album, a UI mock for an AI development tool, and an SEO operations tool. Every one of those repositories began in the same state: the look was already finished.

This article covers how to hand a Figma Make design over to Claude Code (Anthropic's coding agent, which reads and edits a repository from your terminal), and what to tell Figma Make from the very first prompt so the handover goes smoothly. In the second half, I go through the config files and commit history of the projects I built this way, to show how far each one got and where it stopped. It takes about 12 minutes to read.

The last section of this article is the complete prompt I actually pasted into Figma Make. If you would rather see the finished prompt first, you can start there.

The short version

• Hand it over through GitHub. Connect Figma Make to GitHub so the design becomes a repository, then have Claude Code read it and ask: "analyze this code and get it ready for me to take over development." If you are bringing the design into a project that already exists, the step is the same: have Claude Code read the design repository.
• What matters is a structure that is easy to take over, and you get it by asking for it in the prompt. Figma Make is a tool for making designs. Files that make a handover easy (an atomic design structure, which builds the UI from small shared parts upward; tokens taken from the design; a folder layout; written rules; the prompts you used; a summary in the README) only appear when you ask for them. The complete prompt that asks for most of this is at the end of the article.
• Do it before the handover, or once the design has settled. You do not need to put everything in the first prompt. When the design is close to done, ask Figma Make to "switch to atomic design, extract tokens from the design, use this folder layout, and write down the rules and the prompts." The handover gets much lighter.
• The first job after taking it over is not adding features. It is removing duplication. Merge the duplicated parts, connect the tokens, split the huge screens, and reconnect the build. Skip this, and a project that looks finished can sit for months without moving.

The handover, step by step

Connect Figma Make to GitHub

The steps are simple. Once you have built the screens in Figma Make, use the button at the top right to connect it to a GitHub repository. Figma Make then writes to the repository by itself. In the first commits, the author is figma[bot]:

30bb071 Initial commit                    (figma[bot], 2025-12-10)
5ba6dfe Add files from Figma Make         (figma[bot], same day)
81d2e7e Update files from Figma Make       (figma[bot], same day)

The Add files from Figma Make commit is where the handover starts. From there, open the repository in Claude Code and ask it to "analyze this code and get it ready for me to take over development." The exported code runs as it is with npm i && npm run dev. It starts with no extra setup because vite.config.ts maps imports that carry a version number in the name (for example [email protected]) to the installed packages.

Look at the code view, not only the preview

At the top right of Figma Make, next to the design preview (the eye icon), there is a code view (<>). Open it and you can see that Figma Make has written real, working code, not just a design, laid out in atomic design folders. Atomic design is a way of building a UI from the smallest parts upward: atoms (a button, a badge), molecules (a search bar made of an input and a button), organisms (a header, a thread list), templates and pages. This code is what you hand to Claude Code.

src/
├─ app/
│  ├─ App.tsx                 # routing (defines every page)
│  └─ components/
│     ├─ atoms/               # Button / Badge / Input ... (smallest parts)
│     ├─ molecules/           # SearchBar / FormField / Card ...
│     ├─ organisms/           # Header / ThreadList / ChatView ...
│     ├─ templates/           # BaseLayout / TwoColumnLayout ...
│     ├─ ui/                  # the full set of shadcn/ui primitives
│     └─ figma/               # ImageWithFallback (a Figma Make standard)
│  ├─ data/                   # mock data
│  └─ styles/                 # theme.css (design tokens) and others
├─ imports/                   # <- where I had it save the prompts I pasted into Figma
│  └─ pasted_text/
├─ guidelines/Guidelines.md   # <- where to have it write the rules
├─ README.md                  # <- where I have it write Quick Summary / Ask Human
├─ FIGMA_MAKE_PROMPT.md       # <- the prompt to hand over next, as a file
├─ vite.config.ts  package.json

Figma Make did not choose this layout by itself. It is there because I told it "use atomic design, use this folder layout, and keep the prompts and the rules." (What I told it is in the next sections.) Because the code underneath is laid out like this, Claude Code can work out where the atoms are, where the tokens live, and why the UI looks the way it does.

Bringing it into a product that already exists

If you are bringing the design into a product that is already running, the step is the same. Receive the Figma design as a separate repository, and from the main repository ask Claude Code to "read this design repository, analyze it, and bring it into our structure." In an SEO operations tool I built, I kept design/prototype/ (a frozen copy of the code I received from Figma Make) separate from apps/seo-admin/ (the real development), and the commit history records the handover as it happened:

Add files from Figma Make
migrate Figma prototype UI to seo-admin
promote Figma prototype to seo-admin, backup legacy

If you keep the received code as a frozen copy and do the real development in a different directory, you can always look back at where the design started, and regenerating the design in Figma does not overwrite your main code. That project grew to 180 commits and went from a mock all the way to a real backend (multiple tenants, importing outside data, infrastructure).

Figma Make does not write handover files unless you ask

This is easy to get wrong. Claude (Anthropic's model) runs inside Figma Make, and its output comes in a stack Claude Code already knows well: React + TypeScript, Tailwind CSS and shadcn/ui (a set of ready-made UI components that are copied into your code). That much is Figma Make's default.

But Figma Make does not add handover documents on its own. Everything below, which came with the repositories I received, exists only because I wrote "create this" in the prompt:

• The Quick Summary for Claude Code section at the end of README.md (a summary written for the next Claude Code session that reads the repository)
• The Ask Human section in the same README (a list of open decisions a person has to make: Supabase or Firebase, two ready-made backend services, and how to handle saving data, sign-in and the production environment)
• ATOMIC_DESIGN.md, SCREEN_SPEC.md (921 lines in one project), DESIGN_SUMMARY.md, and FIGMA_MAKE_PROMPT.md (the prompt to hand over next, kept in the repository as a file)

Figma Make is a system for making designs. It was not built for handovers. So turn the question around: if certain files would make the handover to Claude Code easier, have Figma Make create them through the prompt. The next section is exactly what to tell it, and the complete prompt that combines it all is at the end.

What to tell Figma Make from the start

There are prompts that leave the look unchanged but change how the code underneath is built. Whether you give them at the start makes a large difference to how hard the handover is later.

• "Build it with atomic design." Without this, Figma Make builds similar pieces of UI separately, and fixing one place does not carry over to the others (examples below).
• "Create a design system (design tokens) from the design you made. Do not hardcode colors or spacing." Design tokens are named values, such as a color or a spacing size, that every component refers to instead of writing the raw value. This is the key point: you do not bring your own design system; you have Figma Make extract the tokens from the design it made itself. Here is an instruction that worked (from the improvement prompt for the SEO operations tool):

0) design system: extract it from this design and turn it into tokens:
   - 8px grid / card padding in two sizes, 16 and 24
   - type scale (H1 24-28 Bold ...)
   - fix what each color means (success=Green / warning=Amber / failure=Red / info=Blue / on hold=Gray)
   - standardize badges (height 24, corner radius 12) and tables (row height 40, numbers right-aligned)
   - from now on, components refer to tokens (no hex or px written directly)

• "Keep the existing design template and style." For the plush-toy album, every time I added a feature I put this at the top of the prompt: "keep the existing design style (soft colors, photo-centered, plenty of white space, rounded card UI)." Repeating it kept the look consistent across every round. Naming existing products as a density reference, such as "about as dense as Linear, Vercel or Stripe," also works.
• "Write the rules in guidelines/Guidelines.md." Figma Make always creates an empty guidelines/Guidelines.md (its first line is Add your own guidelines here). If you have it write rules there, Figma Make follows them too. Yet in every project I looked at, this file had been left empty. Just having it filled in makes a difference.
• "Keep the prompts I give you in src/imports/." Figma Make can save a pasted prompt as a file. If you have it keep those files instead of deleting them, both Claude Code and people can later trace why the UI looks the way it does. In the SEO operations tool, 16 prompts (rounds of redesign, refine and refactor) stayed in the repository and became a record of the design intent.
• "Write a handover summary (Quick Summary for Claude Code) and the questions to ask a person (Ask Human) in the README." The two README sections in the previous section came from this instruction. Files that make a handover easy appear only when you ask for them.
• Give it the folder layout first. If you already have a fixed layout, say "use this layout" at the start.

You do not have to type these into the chat every time. In practice, I put them all in one md file and hand it over as FIGMA_MAKE_PROMPT.md.

Even with atomic design, fixing one place can break another

This is why I always tell Figma Make to use atomic design. But even when you say "build it with atomic design," often only the folders are atomic, and the parts inside are not connected to each other. The first thing Claude Code should do after taking over is fix those connections.

Figma Make itself can see the risk. When I asked it how to add a mobile version to an existing design, it gave three options and rejected the riskiest one on its own:

Here are the patterns I actually found:

• The same idea was built twice in two separate trees. The gift-record app had separate atomic trees for personal mode and business mode, so EventCard and CorporateEventCard, and PersonListItem and CorporateClientListItem, were each defined twice. Because the two trees did not share their low-level parts, fixing one did not change the other. There was also a part that nothing imported (CorporateStatCard).
• Tokens were defined but not connected. The plush-toy album defined earth-tone tokens in theme.css, but the components hardcoded the same colors directly (35 files). The number of files that referred to var(--color-*) was 0. So changing one token in theme.css never reached the screen.
• Two kinds of buttons existed side by side. In the same app, the bundled shadcn/ui button and a custom button both existed, and 46 shadcn parts sat there almost unused.
• The build was not connected. In the AI development tool mock, the CSS that actually applied at runtime was one huge, pre-built file, and tailwindcss was not even installed. Changing a token in globals.css triggered no rebuild. Before starting development in Claude Code, the Tailwind build had to be reconnected first.
• Screens stayed as huge single files. Single screens had grown to 800-900 lines (about 40 KB) each without ever being split; the settings screen alone was 888 lines, about 42 KB. Another screen defined its own TypeBadge with the same name as the shared part. Fixing the badge in one place did not fix the other.

So the right first commit after a handover is removing duplication, not adding a feature (often called making the code DRY: "Don't Repeat Yourself," one definition for each thing). Merge the duplicates, connect the tokens, split the huge screens, reconnect the build. Finish that, then move on to features.

How far each project got, and where it stopped

Apart from the SEO operations tool above (the larger example, where I froze design/prototype/ and went on to real development), here are four small products I started from Figma Make. They had the same starting point, but how far each one got depended on what was inside.

Of the four, the beauty-curation site went furthest. It works as a static site, so I set Next.js (a React web framework) to export static files and put it on AWS Amplify (AWS's hosting service). I also added a CLAUDE.md with standing instructions for Claude Code.

// next.config.ts: export as a static site
const nextConfig: NextConfig = {
  output: "export",
  images: { unoptimized: true },
  trailingSlash: true,
};

output: "export" makes it a purely static site with no server-side rendering (SSR, where a server builds each page on request), and images.unoptimized removes the server-side function (AWS Lambda, which runs and bills per request) that would otherwise optimize images. The hosting side then only serves the exported out/ folder, which keeps running it simple.

The gift-record app and the plush-toy album stopped just before the data layer. The screens and the moves between them are finished, but saving data, sign-in and notifications were never started. Both stopped with the README's Ask Human questions (Supabase or Firebase? which sign-in method?) still unanswered. That groundwork looks like the last 10% of the job, but it is most of the work.

The UI mock for the AI development tool is still a mock. After it came in from Figma Make, no feature commits were added, and it has not moved past the UI stage.

Here is how far the four got, using only facts that can be read from the git history and config files (I am not including made-up figures such as a percent complete):

Later, I put all the repositories I had taken over onto one shared, self-hosted security CI (automated security checks). The same problem came up in every repository: CI scripts written in the older module style failed. Code written by Figma Make assumes the newer style, ES modules ("type": "module" in package.json), so a script in the older CommonJS style saved as a .js file fails with require is not defined. I fixed it across all of them by renaming those scripts to .cjs. To use code that Figma Make wrote in production, you have to do more than add features; you also have to bring it in line with rules like these.

Lessons you can reuse

• There is one way to hand it over. Connect Figma Make to GitHub, then have Claude Code read that repository and ask it to "analyze this and get it ready to take over." Keep the received code as a frozen copy.
• Files that make a handover easy do not appear by themselves. Ask for them. Build it with atomic design / create a design system from the design and do not hardcode / keep the existing style / write the rules in Guidelines.md / keep the prompts in src/imports/ / write a handover summary and Ask Human in the README. Figma Make is a system for making designs, not a handover tool.
• The first job after a handover is removing duplication. Merge the duplicates, connect the tokens, split the huge screens, reconnect the build. Features come after.
• Do not judge progress by how finished it looks. Projects stop where saving data, sign-in and notifications are still missing. Answering the README's Ask Human early is what separates a mock from a product.

The complete prompt to give Figma Make

This is the shape of the "assume a handover" prompt to paste into Figma Make. It is the one I actually used for the mobile design of a tool called Prompt Flow, made general. The real one is this outline plus the spec for every screen (an ID, states and transitions for each screen), about 720 lines in total, and it is itself kept in the repository as FIGMA_MAKE_PROMPT.md.

Below is the general outline of that file. Copy it as it is and add your product name and your list of screens.

You are producing a design AND a clean handoff for Claude Code.

Goal:
- Build the UI in React + TypeScript + Tailwind + shadcn/ui.
- The output will be handed to Claude Code for development, so make it
  legible and safe to take over — not just visually done.

Architecture:
- Use Atomic Design with REAL reuse, not just folders:
  atoms → molecules → organisms → templates → pages.
  Never define the same component twice (no Card and CardV2).
- Derive a design system FROM this design: put every color, spacing,
  radius, and type step into tokens (theme.css). Components must
  reference the tokens — never hardcode hex or px.
- Fix color meanings: success=Green / warning=Amber / error=Red /
  info=Blue / muted=Gray. Standardize badges and tables.

Handoff artifacts — create these files:
- README.md with a "Quick Summary for Claude Code" section and an
  "Ask Human" section listing every unresolved decision
  (backend? persistence? auth? hosting?).
- guidelines/Guidelines.md filled with the rules above
  (do not leave the template empty).
- Keep every prompt I give you under src/imports/, so the design
  intent stays inside the repo.
- SCREEN_SPEC.md: for each screen, its purpose, states
  (loading / empty / error), and transitions.

Constraints:
- Ship a runnable repo: `npm i && npm run dev` must work.
- Do not blindly port every screen; build only what belongs here.
- Every screen needs loading / empty / error / long-content variants.

With this one file, everything Claude Code needs when you hand the project over is inside the repository: what to de-duplicate first, and what has not been decided yet. Skip it, and, as shown above, you get code that looks finished but is not connected inside, and the handover stalls. It does not have to be your first prompt. Run this prompt once before the handover, or once the design has settled. Figma Make takes you as far as the design. This one extra step is what makes everything after it lighter.

Articles on our small products and experiments will continue as a series. If you are interested, please like and follow.

Our other products are listed at https://www.eln.ne.jp/products

EarthLink Network builds its own products to run the whole company on AI — each one born from a need along the way. See the full index of what we build:

→ The 18 products EarthLink Network builds in-house

For more about the company and each product, visit www.eln.ne.jp.