From Figma
to Storybook_

Your team already has a component library, but parts are outdated, tokens are inconsistent, and things don’t quite match the codebase. This is the workflow I’m exploring to clean up that foundation and bring components into code with clear instructions for using them.

Start with one component. Use a button to work through the process: audit the foundations, define what’s missing, and build a documented component in Storybook. Once your team has reviewed that first example, you have a process to repeat.

The prompts below are reusable templates for each step. Replace the bracketed text with your project details.

Before you start

Have your Figma library, access to the actual product repository, and any existing component documentation ready. Work with your engineers to get the repository running and agree on a branch for the changes.

For this workflow, I use Conductor with Figma Console MCP connected. This guide assumes you already have your AI workspace and Figma connection configured. The first check is whether the agent can actually read the right file.

Prompt: Confirm the source

Use Figma Console MCP to inspect [Figma file/link].
Confirm that you can see the variable collections and [component name].
Tell me which file and collections you inspected.
Do not make changes yet. If you cannot access Figma, tell me directly.

An agent can inspect the codebase when you intended it to inspect Figma. Confirm the exact file and collections before relying on its findings.

1. Audit the tokens behind your components

Start with the variables your component depends on. In this workflow, primitive tokens hold the base values, while semantic tokens describe how those values are used. A semantic token for a background, for example, can reference a primitive color.

Raw hex values, missing primitives, and duplicates can accumulate as a component library grows. Ask AI to identify those gaps before deciding what to change.

Prompt: Audit the foundations

Audit the color variables in [Figma file/collection].
Identify semantic tokens using raw hex values, matching primitives,
missing primitives, possible duplicates, and opacity differences.
Check the light and dark modes where they exist.

For each finding, show the token name, current value or reference,
proposed change, and reason. Keep findings separate from recommendations.
Do not edit the library yet.

Review the proposed mappings with your team. A matching color value alone does not explain the intended role of a token; preserve the meaning behind the names and usage rules.

2. Clean up and check the result

Work through the agreed changes in small groups. Creating new primitives is only part of the cleanup. Ask the agent to update the semantic references, then inspect what remains.

Prompt: Apply the agreed changes

Apply these agreed token changes: [list changes].
Create the missing primitives we selected and update the semantic
references to use them. Preserve the intended light and dark values.

Show what changed and re-audit the affected tokens.
List anything that is still unresolved. Do not delete other tokens.

Check the variables directly in Figma. Confirm that references resolve, the intended values remain, and the agent has completed both parts of the change.

You can also ask it to build a visual reference from the variables, with swatches, names, modes, and usage descriptions. That makes it easier to inspect the colors and explain when they should be used.

3. Define one component before building it

Choose a component your team already uses. Inspect the Figma version alongside any existing implementation and team guidelines, then work through the questions below.

Prompt: Find the gaps

Inspect [component/link] in Figma, its existing implementation in
[repository], and [team documentation]. Work through the component
questions above before building anything.

Identify the source of each answer. Separate verified facts,
recommendations, and unknowns. Flag disagreements between Figma,
code, and documentation.

Ask me the unresolved questions that affect correct use or behavior.
Do not invent product rules. Wait for those answers before implementing.

This is where your team’s product knowledge matters. If Figma and code disagree, decide what the component should do and record that decision so it can travel with the implementation.

4. Bring the component into Storybook

Use your existing Storybook setup if you have one. If you’re starting fresh, have the agent inspect the repository and consult the current official Storybook documentation for your project’s framework before proposing the setup.

Once the setup and component decisions are agreed, move into implementation.

Prompt: Build and document the component

Using the confirmed component answers, implement or update
[component] in this repository and document it in our Storybook.
Reuse the existing implementation where appropriate.

Follow the project's conventions for component documentation,
JSDoc, stories, and MDX where applicable.

Create focused examples for the supported variants and states.
Explain when and why to use them. Include usage guidelines,
specific mistakes to avoid, and appropriate alternatives.

Keep the implementation and documentation consistent with the
confirmed rules. Show the changed files and how to review the result.

The useful output is a component your team can inspect alongside the reasoning for how to use it. Include relevant product guidelines so those rules remain visible when the component is reused.

5. Review before repeating

Check the agent’s work throughout the process and involve your engineers in reviewing the implementation. Use the feedback from your first component to refine the next one.

Prompt: Check the result

Compare the implemented component and its Storybook documentation
against our confirmed rules and Figma source.

Check the supported variants, states, token references, and examples.
Run the relevant checks available in this project.
Report what you verified, any mismatches, and anything you could
not check. Show the evidence for your findings.

Before moving to the next component, review these five things with your team:

• The intended tokens are connected and render correctly in supported modes.
• The component follows the agreed properties, variants, and behavior.
• Examples explain correct usage and unsupported combinations.
• Documentation matches the implementation and records the sources of key decisions.
• Remaining questions are visible, and engineering has reviewed the changes.

Save the confirmed answers and prompts as a starting point for the next component. Adapt them as you move from simple controls to components with more product-specific behavior.

The more clearly we document how our components work, the more useful they become for the whole product team. I’m exploring how that shared context can help AI build on what we already have, with more consistent design and less rebuilding during implementation.

Keep building with your team

Explore a Product Sprint with TDP · Join the TDP Community