# Flowpoint

> On-Prem Agentic Website Analytics. On-premise website analytics with an AI agent and MCP server. Deployed inside your own environment — your data, your model, fully private. Your analytics never leave your infrastructure. Licensed software, not SaaS.

Sitemap: https://flowpoint.ai/sitemap.xml
Full text: https://flowpoint.ai/llms-full.txt
Feed: https://flowpoint.ai/rss.xml

## Product

- [Flowpoint](https://flowpoint.ai): On-premise website analytics with an AI agent and MCP server. Deployed inside your own environment — your data, your model, fully private. Your analytics never leave your infrastructure. Licensed software, not SaaS.
- [MCP Server](https://flowpoint.ai/mcp): Flowpoint ships a built-in MCP server, so Claude, Claude Code, Cursor and any MCP client can query analytics and build dashboards inside your own environment.
- [Documentation](https://flowpoint.ai/docs): Installation, tracking script setup and custom events.
- [About](https://flowpoint.ai/about): About Flowpoint, the company behind on-premise agentic analytics.
- [Contact](https://flowpoint.ai/contact): Request a license or ask about an on-premise deployment.

## Blog

Guides on moving UI design out of design tools and into AI coding agents.

- [How to export a UI design to a coding agent](https://flowpoint.ai/blog/export-ui-design-to-coding-agent): There are only three ways a design reaches a coding agent: a live MCP connection, a file export, or a handoff bundle. Each carries a different amount of your intent. Here is how to pick, wire up and sanity-check the route for your tools.
- [Figma to a coding agent: what the MCP server actually sends](https://flowpoint.ai/blog/figma-to-coding-agent): Figma sends a selection, not a file. Here are the commands for each agent, what actually arrives on the other end, and the specific reason well-built files still produce off-system code.
- [Canva to a coding agent: the export path, not the MCP server](https://flowpoint.ai/blog/canva-to-coding-agent): The Canva MCP server is for building Canva apps, not reading your designs. The real route is an asynchronous Connect API export — and the format you choose decides how much structure survives.
- [Claude Design to Claude Code: the handoff bundle explained](https://flowpoint.ai/blog/claude-design-to-claude-code): A bundle is assembled by the thing that made the design, while the reasoning is still in context. That makes it the highest-fidelity handoff available — and it still will not keep two screens built weeks apart consistent.
- [Which coding agent handles design context best](https://flowpoint.ai/blog/coding-agents-design-context): The interesting difference between these five is not model quality. It is whether the design route you set up survives a git clone, and none of them carries your design decisions between sessions.
- [Your agent is not ignoring your design — it never got the rules](https://flowpoint.ai/blog/design-files-vs-design-rules): Every handoff route sends what a design contains. None of them sends why. That missing half is small, writable in an afternoon, and the reason generated screens keep drifting off-brand.

## Case studies

- [How Rentoza Enhances Customer Journeys](https://flowpoint.ai/customers/rentoza): Leveraging Flowpoint to overcome drop-off challenges and optimize website performance.
- [How ActionVFX is Mastering User Behavior Intelligence](https://flowpoint.ai/customers/actionvfx): How a special-effects giant mastered user behavior and boosted conversions.

## Free tools

Every tool below also registers WebMCP tools, so a browser AI agent can call the
calculation directly instead of filling in the form. See https://flowpoint.ai/mcp for the list.

- [Free PPTX to PDF Converter](https://flowpoint.ai/tools/pptx-to-pdf): Convert a PowerPoint presentation to PDF in your browser — one page per slide, nothing uploaded to a server.
- [Free PDF to PPTX Converter](https://flowpoint.ai/tools/pdf-to-pptx): Convert a PDF into an editable PowerPoint file in your browser — one slide per page, nothing uploaded to a server.
- [Free PDF Compressor](https://flowpoint.ai/tools/compress-pdf): Reduce the file size of a PDF in your browser — choose a compression level and download a smaller file.
- [Free Logo Color Changer](https://flowpoint.ai/tools/logo-color-changer): Upload a logo image and convert it to black, white, or a custom color, and then download the recolored logo.
- [Make Logo White in 1 Click — Free Transparent PNG](https://flowpoint.ai/tools/make-logo-white): Upload your logo, get a transparent white PNG in seconds.
- [Free QR Code Generator](https://flowpoint.ai/tools/qr-code-generator): Generate a QR code based on an URL or text.
- [Free UTM Link Builder](https://flowpoint.ai/tools/utm-builder): Create a custom UTM link and copy it to your clipboard.
- [Free Email Signature Generator](https://flowpoint.ai/tools/email-signature-generator): Create an HTML email signature — no coding experience required.
- [Free Timezone Converter](https://flowpoint.ai/tools/timezone-converter): Quickly find the time for any city in the world.
- [Free WCAG Contrast Checker](https://flowpoint.ai/tools/contrast-checker): Check the contrast between a foreground text color and a background color.
- [Free APCA Contrast Calculator](https://flowpoint.ai/tools/apca): Calculate the APCA contrast level of two colors.
- [Free Color Palette Generator](https://flowpoint.ai/tools/color-palette-generator): Get color inspiration for your projects.
- [Free Color Transparency Generator](https://flowpoint.ai/tools/color-transparency): Input a color and get transparency variations.
- [Free Conversion Rate Calculator](https://flowpoint.ai/tools/conversion-calculator): Calculate a website vistior-to-conversion value as a percentage.
- [Free Conversion Rate Comparison Calculator](https://flowpoint.ai/tools/conversion-comparison-calculator): Compare conversion rates between two data sets.
- [Free NPS Calculator](https://flowpoint.ai/tools/nps-calculator): Calculate NPS based on the total number of Promoter, Passive, an Detractor scores from your survey.
- [Free Percentage Increase/Decrease Calculator](https://flowpoint.ai/tools/percentage-calculator): Calculate the percentage increase (or decrease) between two numbers.
- [Free Times Increase/Decrease Calculator](https://flowpoint.ai/tools/times-increase-calculator): Calculate the increase or decrease between two numbers.
- [Free Meta Description Generator](https://flowpoint.ai/tools/meta-description-generator): Easily generate meta descriptions for your website pages.
- [Free Alt Text Generator](https://flowpoint.ai/tools/alt-text-generator): Free alt text generator for images Alt Text Generator is a free online marketing tool from Flowpoint.
- [Free Reading Comprehension Test Tool](https://flowpoint.ai/tools/readability-test): Test the readability of your text against Flesch-Kincaid grade level and reading ease metrics.
- [Free Website Hero Section Generator](https://flowpoint.ai/tools/website-hero-generator): Get hero section title, description, and CTA button recommendations for your website.

---

# Full article text

# How to export a UI design to a coding agent

URL: https://flowpoint.ai/blog/export-ui-design-to-coding-agent
Published: 2026-08-17
Tags: Design to code, AI coding agents, MCP

There are only three ways a design reaches a coding agent: a live MCP connection, a file export, or a handoff bundle. Each carries a different amount of your intent. Here is how to pick, wire up and sanity-check the route for your tools.

## The handoff problem, stated precisely

A coding agent that builds UI needs two different things from you, and almost every handoff workflow only supplies one of them. The first is the design itself — this screen, these elements, at these positions, in these colours. The second is the design system behind it — which typeface owns headings, what the accent colour is allowed to touch, how much space a card gets, what your product never does. Exports are very good at the first. They carry essentially none of the second.

That gap is why a generated screen so often looks right in isolation and wrong next to the rest of the product. The agent received geometry and inferred everything else from the statistical average of its training data. It is not ignoring your design system; it never received one. We cover that argument on its own in why your agent never got the rules — this guide is about the mechanical half: getting the design across cleanly in the first place.

## Three shapes a handoff can take

Whatever tools you use, the design reaches the agent in one of three shapes. Knowing which one you are in tells you what to expect from the output, and where to spend your effort.

- A live MCP connection: The design tool runs a server, the agent connects to it, and the agent pulls a selection on demand. Figma Dev Mode works this way. The design stays in the design tool and the agent asks for it when it needs it, so re-running a prompt picks up whatever changed since. This is the highest-fidelity route when it is available.
- A file export: You render the design to files — HTML, PDF, images — put them somewhere the agent can read, and point at them. Canva works this way, and so does anything without a server. Fidelity depends entirely on which format you pick; the difference between a structured HTML bundle and a PNG is the difference between a document and a photograph of one.
- A handoff bundle: The tool that made the design packages it for the agent while the reasoning is still in context. Claude Design does this for Claude Code. Nothing is re-interpreted from pixels or markup, because the thing assembling the package is the thing that made the decisions.

The three are ordered by how much intent survives, not by how convenient they are. A bundle beats a live connection on intent within a single screen; a live connection beats an export on freshness. All three lose the same thing at the end, which we get to below.

## Pick the route by source tool

Design tool | Route | What actually moves
Figma | Dev Mode MCP server | A selection — node tree, component structure, bound variable values, Code Connect mappings
Canva | Connect API export | Rendered files. Use html_bundle; the MCP server is for building Canva apps, not reading designs
Claude Design | Handoff bundle | The design plus the reasoning that produced it, assembled in-context
Framer | Token export | Design tokens; components come across as published output, not source
Sketch | Built-in MCP server | Layer tree, assets, and live document access
Photoshop / XD | File parsing | Layer structure read out of the file directly, no vendor server involved

Two of these have a trap worth naming up front. Canva publishes an MCP server, but it connects agents to Canva's developer documentation so they can build Canva apps — it does not hand your designs to an agent. The export path is the real route, and it is covered in Canva to a coding agent. Figma's Dev Mode server, meanwhile, only accepts connections from clients in its own catalogue, which quietly excludes Lovable; the details are in Figma to a coding agent.

## Wire the agent up once, not per prompt

Every agent in this space reads a project instructions file before it starts working. Putting the handoff details there — where exports live, which server is connected, what the export format does and does not preserve — means you stop re-explaining it in every session, and so does everyone else on the team.

Agent | Instructions file | MCP config
Claude Code | CLAUDE.md | claude mcp add, or the settings file
Cursor | .cursor/rules/*.mdc (glob-matched) | .cursor/mcp.json at the repo root
Codex | AGENTS.md | ~/.codex/config.toml, user-level
Replit | AGENTS.md | .replit, with tokens in Replit Secrets
Lovable | AGENTS.md | Settings UI — no config file

Note which of those travel with the repository. Cursor and Replit keep configuration in committed files, so a teammate who clones the repo inherits the same design route. Codex keeps it user-level, which means every person sets it up themselves. That distinction decides whether your handoff is a team capability or a personal habit, and it is the main axis in which coding agent handles design context best.

Instructions files compete with your actual prompt for attention. Aim for well under 200 lines, and put durable facts in it — export locations, format caveats, naming conventions — rather than a copy of your design system. The system belongs somewhere the agent can query on demand, not somewhere it has to carry all session.

## Send one screen at a time

The most common self-inflicted failure is sending too much. A whole Figma page, an entire Canva presentation, a folder of exports — each one arrives as a large structured description that fills the context window before any code is written. The agent then works from a compressed impression of everything instead of a precise reading of one thing.

Select one frame. Build it. Confirm it. Move to the next. This is slower to type and considerably faster to finish, because the failure mode of the alternative is a full rebuild rather than a small correction.

## What none of the three routes carry

Here is the thing every route has in common. A live connection, an export and a bundle all describe a design that exists. None of them explains a design that does not exist yet. Ask any agent for a screen you never drew — a settings page, an empty state, a billing error — and it has nothing to consult. It infers, and inference drifts.

The information it needs is not in the file, because it was never written down anywhere. It sounds like this:

- Colour roles, not hex codes: Not "#287F71" but "this is the single accent; it appears on primary actions and active states, and nowhere else". A hex code in an export tells the agent what was used once. A role tells it what to do next time.
- Type ownership: Which typeface owns headings, which owns body, which sizes are in the scale — and which sizes are not, so the agent stops inventing a 19px heading between two real ones.
- Spacing and motion values: The actual numbers. A spacing scale and a transition duration are two of the cheapest things to specify and two of the most visible when they are wrong.
- Who the copy is for: Name the audience. "Technical buyers evaluating an on-prem tool" produces different microcopy from "first-time users", and the agent will otherwise pick a generic register.
- The never list: Negative constraints do the heaviest lifting of anything on this list. No gradients on surfaces, never centre body copy, no emoji in product UI — each one closes off a whole family of plausible-looking wrong answers.

Where that lives matters as much as what it says. In a prompt, it works once and is gone. In a repository markdown file, it works for that repository — which is fine until you have four repositories and three clients, and the four copies quietly diverge. What it wants to be is a single source the agent can read on demand, over the same MCP transport it already uses for everything else.

## Test it

One check tells you whether your handoff moved a design or a design system. Hand the agent a screen through whichever route you set up, and let it build. Then ask it for a screen that does not exist anywhere in the design file — a settings page is the usual choice, because everyone needs one and nobody designs it first.

Compare the two. If the second screen reuses your heading sizes, your accent, your spacing rhythm and your tone of voice, the route carried your system. If it is visibly a different product — new typographic scale, a colour you have never shipped, copy in a register you do not use — then the handoff moved one design, and the rules never arrived. That is a fixable problem, and it is fixed in a different place from the export.

## Frequently asked questions

### Can a coding agent read a Figma file directly?

Not the file. Figma exposes a Dev Mode MCP server that sends the current selection — a node and component tree with bound variable values and any Code Connect mappings — rather than the whole document. You select a frame in Figma and the agent receives a structured description of it.

### What is the best export format for handing a design to an AI agent?

A structured HTML bundle, where assets stay as separate files and element boundaries survive. It preserves structure the agent can reason about. Standalone HTML with inlined base64 assets wastes context, and PNG or JPG discards structure entirely and forces the agent to infer everything from pixels.

### Why does generated UI still look off-brand after a good handoff?

Because the export describes what a design contains, not why. The agent cannot tell an intentional design token from an incidental one-off value, and it has nothing at all to consult for screens that were never designed. Design rules have to travel separately from the design file.

### Do I need MCP to hand a design to a coding agent?

No. MCP is the highest-fidelity route where the design tool offers a server, but a committed file export that the agent reads from the repository works with any agent and any design tool, including tools with no integration at all.

---

# Figma to a coding agent: what the MCP server actually sends

URL: https://flowpoint.ai/blog/figma-to-coding-agent
Published: 2026-08-17
Tags: Design to code, AI coding agents, MCP

Figma sends a selection, not a file. Here are the commands for each agent, what actually arrives on the other end, and the specific reason well-built files still produce off-system code.

## It sends a selection, not a file

The first thing to internalise about Figma's MCP server is the unit of transfer. It is not the document. You select a frame or a component in Figma, and the agent receives a structured description of that selection — the node hierarchy, the component tree, the values of any variables bound to properties, and any Code Connect mappings that link a Figma component to a component in your codebase.

This is a much better payload than a screenshot, and it changes what you should ask for. The agent is not looking at a picture and guessing at structure; it has the structure. What it does not have is the rest of the file, the rest of the product, or any account of why the design is the way it is. This post covers the mechanics; the wider picture is in how to export a UI design to a coding agent.

## Turn the server on

Figma runs two servers. The remote one at mcp.figma.com is the recommended route and needs no local app running. The desktop one runs locally out of the Figma desktop app and is useful when you want the agent reading whatever is selected on screen right now. Enable the desktop server from Dev Mode in the Figma desktop app — toggle Dev Mode in the bottom toolbar, then enable the MCP server in the inspect panel — before any client can reach it.

The desktop app spins up its local server on port 3845 whenever it is running, and that local entry can end up registered alongside the remote one. Two servers exposing similar tools is a reliable way to get confusing results. Pick one per project.

## Claude Code

# Remote server (recommended)
claude mcp add --transport http figma https://mcp.figma.com/mcp

# Or the local desktop server, with Figma desktop running in Dev Mode
claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp

Restart Claude Code so it picks up the change, then run `/mcp` to confirm the server is listed and connected. Once it is, add a line to `CLAUDE.md` saying the Figma server is available and that designs arrive as selections — otherwise every new session starts by rediscovering it.

## Cursor

Cursor reads MCP configuration from a file at the repository root, which means committing it hands the same design route to everyone who clones the repo.

{
  "mcpServers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

Pair it with a rule file under `.cursor/rules` scoped by glob to your component directories. Figma knows nothing about your local components unless Code Connect tells it, so the rule is where you say "reuse what is in `src/components/ui` before creating anything new".

## Codex, Replit and Lovable

codex mcp add figma --url https://mcp.figma.com/mcp

That writes to `~/.codex/config.toml` under an `[mcp_servers.figma]` block. Note the path: it is user-level, so it does not travel with the repository and every teammate configures it themselves. Replit is the opposite — configuration goes in `.replit` and travels with the project, but the token belongs in Replit Secrets rather than the file.

Lovable is the exception, and it is worth knowing before you plan a workflow around it. Figma's server only accepts connections from clients in its own catalogue, and Lovable is not in it. The route there is the Builder.io plugin: export the frame from Figma with the plugin, then open the result in Lovable. That is a one-time conversion rather than a live connection — later changes in Figma do not propagate — and Auto Layout stops being best practice and becomes load-bearing, because it is what the conversion uses to infer structure.

## How far Code Connect reaches

Code Connect is the strongest lever available on the Figma side. It maps a Figma component to the real component in your codebase, so the agent writes `<Button variant="primary">` instead of reconstructing a button out of divs and padding. Where it is configured, output quality rises sharply.

The limit is exactly the mapping. Anything outside a mapped component is regenerated from scratch — layout wrappers, one-off sections, anything designed last week and not yet connected. A file with fifteen mapped components and a hand-built marketing section will produce excellent code for fifteen things and invented code for the section.

## Why the output still comes back subtly off

Here is the failure that survives a well-built file, bound variables and configured Code Connect. The generated screen has hard-coded colours where you have tokens, typography that is close to yours but overridden by a few pixels, and hand-written CSS where a utility existed. Nothing is badly wrong. Everything is slightly wrong.

The reason is that the server describes what exists, not what is intentional. A variable bound to a fill and a colour someone typed in by hand during a rush both arrive as a colour on a node. The agent has no way to tell a design token from an incidental value, so it treats them identically — and reproduces both faithfully, including the mistake.

The other half of the problem shows up the moment you ask for a screen that is not in the file. There is no selection to send. The agent falls back on inference, and inference produces a plausible screen belonging to a slightly different product.

## Keep selections small

Selection scope is a context budget decision. Selecting a whole page sends a large structured description that consumes the window before a line of code is written, and the agent ends up working from a compressed impression rather than a precise reading. One frame per request, confirmed before moving on, is both more accurate and — because the failure mode is a small correction rather than a rebuild — faster in practice.

## Test it

Generate a screen from a Figma selection. Then ask for one that does not exist in the file — a settings page, a 404, an empty state. If the second screen is visibly a different product, the handoff moved your design and not your design system. That is not a Figma configuration problem and no amount of Code Connect will fix it; the missing piece is a set of rules the agent can read that are true across every screen, including the ones nobody has drawn yet. That argument is laid out in why your agent never got the rules.

## Frequently asked questions

### What does the Figma MCP server send to a coding agent?

The current selection, not the file. That means the node hierarchy and component tree of the selected frame, the values of variables bound to its properties, and any Code Connect mappings that link Figma components to components in your codebase.

### How do I connect Figma to Claude Code?

Run "claude mcp add --transport http figma https://mcp.figma.com/mcp" for the remote server, or point it at http://127.0.0.1:3845/mcp for the desktop server with Figma running in Dev Mode. Restart Claude Code and run /mcp to confirm the connection.

### Can Lovable connect to the Figma MCP server?

No. Figma's MCP server only accepts connections from clients in its catalogue, and Lovable is not one of them. The route is the Builder.io plugin — export the frame and open the result in Lovable — which is a one-time conversion rather than a live connection.

### Why does Figma-generated code use hard-coded colours instead of my tokens?

Because the server describes what a node contains rather than why. A colour bound to a variable and a colour typed in by hand look the same on the wire, so the agent cannot distinguish an intentional token from an incidental value and reproduces both literally.

---

# Canva to a coding agent: the export path, not the MCP server

URL: https://flowpoint.ai/blog/canva-to-coding-agent
Published: 2026-08-17
Tags: Design to code, AI coding agents, Workflow

The Canva MCP server is for building Canva apps, not reading your designs. The real route is an asynchronous Connect API export — and the format you choose decides how much structure survives.

## The MCP server is the wrong door

Canva publishes an MCP server, and if you have spent any time connecting agents to design tools your instinct will be to reach for it. It is the wrong door. That server exists for engineers building Canva apps and integrations — it connects an agent to Canva's developer documentation so the agent can write code *for* Canva. It does not extract anything *from* your designs.

The route that actually moves a design is the Connect API export. It is less elegant than a live MCP connection and it puts files in your repository instead of a socket between two tools — but it works with every agent, including ones with no Canva integration whatsoever, and the artefacts it produces are diffable. The three transport shapes and when each applies are covered in how to export a UI design to a coding agent.

## The export is a job, not a request

The single most common implementation mistake here is treating the export as a synchronous call. It is not. Rendering takes time and the API does not block, so an export runs as a three-step job.

- Create the job: POST to the exports endpoint with the design ID and the format you want. The response gives you a job with an ID and a status.
- Poll for completion: GET the job by ID until its status stops being in progress. This is the step people skip.
- Collect the download URLs: A completed job carries the links to the rendered files. Fetch them and write them to disk.

# 1. Create the export job
curl -X POST 'https://api.canva.com/rest/v1/exports' \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{ "design_id": "<design-id>", "format": { "type": "html_bundle" } }'

# 2. Poll until the job is no longer in progress
curl 'https://api.canva.com/rest/v1/exports/<export-id>' \
  -H 'Authorization: Bearer <token>'

# 3. Download the URLs the completed job returns

Get this wrong and the failure is quiet rather than loud. A naive single request returns a job that has not finished, your script writes nothing, and the export looks empty rather than unfinished. Then you spend twenty minutes wondering why Canva exported a blank design.

## Pick the format deliberately

Canva can render to `pdf`, `jpg`, `png`, `gif`, `pptx`, `mp4`, `csv`, `html_bundle` and `html_standalone`, with availability varying by design type. For handing a design to a coding agent, the choice matters more than anything else in this workflow.

Format | What the agent gets | Use it?
html_bundle | Document structure preserved, assets kept as separate files with real references | Yes — the default
html_standalone | Same structure, every asset inlined as base64 | Only if you cannot handle multiple files
pdf | Text stays text, inside a fixed page model | Acceptable fallback
png / jpg | Pixels. All structure must be inferred | No, despite being the common choice

The gap between the top and bottom row is the whole game. With `html_bundle` the agent reads element boundaries and points at real image files. With a PNG it is reverse-engineering a layout from a picture, which is exactly the task everyone assumed AI would be good at and which produces the least reliable results of anything here. `html_standalone` looks convenient and is not: inlined base64 blobs are enormous, and they consume the context window that should be spent on your code.

## Commit the export, then point the agent at it

Write exports into the repository under a predictable path and commit them. This turns a design into a first-class input the agent reads the way it reads any other file — and, more usefully, gives you a diff when the design changes.

design/
  canva/
    pricing-page/
      index.html
      assets/
    onboarding-email/
      index.html
      assets/

Then document it once in the project instructions file — `CLAUDE.md` for Claude Code, `AGENTS.md` for Codex and Replit, a rule file under `.cursor/rules` for Cursor. Two sentences is enough: where exports live, and what the format does to the design. That second sentence matters more than it looks, because it prevents a specific misreading covered next.

## What the export loses

Canva exports arrive flat and absolutely positioned — a stack of elements with coordinates rather than a nested hierarchy of containers. Three consequences follow, and an agent that has not been warned will get all three wrong.

- Position does not imply grouping: Three elements sitting next to each other are not marked as related. The agent has to infer that they form a card, and it will sometimes infer differently on the next screen.
- There is no responsive intent to recover: Nothing in the export says what should wrap, stack or hide at a smaller width, because that intent never existed in the source. Anything the agent produces for mobile is invention.
- Text sizes are literal, not semantic: A heading is 34px, not "heading level two". Build several screens this way and you accumulate a set of one-off sizes rather than a type scale.

And the omission that matters most: Brand Kits do not come with the export. Your palette, fonts and logo variants live in Canva and stay there. The agent receives one design's geometry with no account of what any colour means, which typeface owns which role, or what the system permits. Told nothing, it fills the gap with the average of everything it has seen.

## Supply both inputs

A working Canva handoff is therefore two inputs, not one: the export, which describes this design, and a set of brand rules the agent can read, which describe every design. Colour roles rather than bare hex codes, the type scale and who owns each level, real spacing values, the audience the copy addresses, and an explicit list of things your product never does.

If you only supply the first, you get a faithful reproduction of one screen and guesswork for everything after it. Our contrast checker and colour palette generator are useful for pinning down the palette side of that before you write it down.

## Test it

Export a design as `html_bundle` and ask the agent to build the page. Then ask it for a new section in the same style — one that was never in the Canva design. If it reuses your typography and colour hierarchy, the export carried enough structure and your rules are reaching it. If it invents new sizes and a new accent, you have just confirmed the split: the export moved geometry, and nothing moved the system.

## Frequently asked questions

### Can a coding agent read my Canva designs through the Canva MCP server?

No. Canva's MCP server connects agents to Canva's developer documentation so they can build Canva apps and integrations. It does not extract your designs. Use the Connect API export instead.

### Which Canva export format is best for AI coding agents?

html_bundle. It preserves the document's structure and keeps assets as separate files, so the agent sees element boundaries and real image references. html_standalone inlines everything as base64 and wastes context, and PNG or JPG discards structure entirely.

### Why is my Canva export empty?

Almost always because the export was treated as a synchronous request. Creating an export starts an asynchronous job; you have to poll the job by ID until it completes before the download URLs exist. An unfinished job looks like an empty export.

### Does a Canva export include my Brand Kit?

No. Palettes, fonts and logo variants stay in Canva. The export carries one design's geometry with no indication of what colours mean or which typeface owns which role, so brand rules have to reach the agent separately.

---

# Claude Design to Claude Code: the handoff bundle explained

URL: https://flowpoint.ai/blog/claude-design-to-claude-code
Published: 2026-08-17
Tags: Design to code, AI coding agents, Workflow

A bundle is assembled by the thing that made the design, while the reasoning is still in context. That makes it the highest-fidelity handoff available — and it still will not keep two screens built weeks apart consistent.

## Why a bundle beats an export

Every other design handoff in this series has the same structural weakness: something renders the design to an artefact, and something else reads that artefact back. Between those two steps sits an interpretation, and interpretations lose things. A PNG loses structure. An HTML export loses grouping and responsive intent. Even a live MCP connection sends what a node contains rather than why it contains it.

A handoff bundle avoids that step entirely. It is assembled by the tool that made the design, while the reasoning behind the design is still in context. Nothing is re-derived from pixels or markup, because the thing doing the packaging is the thing that made the decisions. Of the three transport shapes in how to export a UI design to a coding agent, this is the one that loses the least.

## What is in the bundle

When a design is ready to build, Claude packages it into a handoff bundle you pass to Claude Code with a single instruction. By default that bundle carries three things.

- The design files: The project's designs themselves, in a form the coding agent can download and read.
- The chat: The conversation that produced the design. This is the part no export format has an equivalent for — the discussion of why a layout changed, what was tried and rejected, what a section is for.
- A README: Instructions telling the model how to interpret the designs, plus a prompt you can paste into Claude Code — or another coding agent — that includes the bundle's URL.

That last detail is worth noticing: the bundle is addressable by URL and comes with its own prompt, so it is not locked to one agent. The handoff is most valuable when your codebase is linked, because Claude Code already understands the components and patterns the prototype was built against and continues from your existing work rather than rebuilding from a screenshot.

## It runs in both directions

The design does not have to come first. From the terminal, `/design` creates, edits and syncs design projects without leaving Claude Code — importing a design into the codebase, turning existing code into a live prototype, or carrying a project through end to end.

# Create, edit and sync design projects from the terminal
/design

# Pull your existing design system into Claude Design,
# so new work starts from your real components
/design-sync

`/design-sync` is the more interesting of the two for anyone with a shipped product. It pulls your design system in, so what you build on the design surface starts from your existing components instead of inventing parallel ones that later have to be reconciled. If you have a component library, run it before you design anything.

## What survives, and what does not

Within a single screen, the bundle holds up well. Visual decisions survive, structure is coherent, and the code that comes out reads like it was written against your components rather than around them. This is genuinely the best handoff currently available, and it is not close.

The gap opens across sessions. Ask for a settings page on Monday and a billing page on Thursday, and the two will not necessarily agree. The heading scale may shift. The accent may land on a different element. The microcopy may change register. Nothing went wrong in either session — the problem is that the system was re-derived each time rather than consulted.

A re-derived system is inferred fresh from whatever is in context: the design, the code it can see, the phrasing of your prompt. A consulted system is read from a fixed source that returns the same answer on Monday and Thursday. The first is an impressive default. The second is what keeps a product looking like one product.

## Write the system down somewhere it can be read

The fix is not a longer prompt. It is recording the decisions somewhere an agent consults on its own, every session, without you remembering to attach anything. What belongs there:

- Typeface assignments, including the restrictions: Which face owns headings, which owns body, and which sizes exist in the scale — stating what is not in the scale prevents the invented in-between size.
- Colours with functional labels: Not a list of hex codes but a set of roles: this is the accent and it appears only on primary actions; this is the surface; this is the destructive state.
- Specific spacing and motion values: The numbers, not adjectives. "Snappy" is not a duration and no two sessions will resolve it the same way.
- The audience, by name: Copy tone follows from who is reading. Name them and the register stops sliding between screens.
- The non-negotiables: Negative constraints work hardest of anything on this list. Each "never" closes off an entire family of plausible-but-wrong outputs before the agent explores it.

A markdown file in the repository is a reasonable first move and costs nothing. It stops scaling at the second repository, and stops working entirely at the third client — an argument we make properly in why your agent never got the rules.

## Test it

Find two screens the same agent built for you weeks apart, in different sessions. Put them side by side and check three things: the accent colour and where it lands, the heading size, and the tone of the microcopy. If all three agree, your system is being consulted from somewhere stable. If they diverge, it is being re-derived every session — and the bundle, however good, was never the thing that could fix that.

## Frequently asked questions

### What is a Claude Design handoff bundle?

A package Claude assembles when a design is ready to build. By default it contains the project's design files, the chat that produced them, and a README telling the model how to interpret the designs — plus a prompt, including the bundle's URL, that you can paste into Claude Code or another coding agent.

### What is the difference between /design and /design-sync?

/design creates, edits and syncs design projects from inside Claude Code — importing a design into your codebase or turning code into a live prototype. /design-sync pulls your existing design system into Claude Design, so new design work starts from your real components.

### Why do two screens built in different sessions look inconsistent?

Because the design system is being re-derived from context each session rather than consulted from a fixed source. Each session infers a reasonable system from what it can see, and reasonable inferences made a week apart do not have to match.

---

# Which coding agent handles design context best

URL: https://flowpoint.ai/blog/coding-agents-design-context
Published: 2026-08-17
Tags: AI coding agents, Design to code, MCP

The interesting difference between these five is not model quality. It is whether the design route you set up survives a git clone, and none of them carries your design decisions between sessions.

## The comparison that matters

Comparisons of coding agents usually turn into comparisons of the models behind them, which changes monthly and is not the constraint most teams actually hit. The constraint that bites is duller and more durable: where each agent keeps its configuration, whether that configuration travels with the repository, and which instructions file it reads before it starts. Get those wrong and it does not matter how good the model is — half your team is working without the design route you set up.

Agent | MCP config location | Travels with the repo | Instructions file | In Figma's MCP catalogue
Claude Code | claude mcp add, or the settings file | If committed | CLAUDE.md | Yes
Cursor | .cursor/mcp.json at the repo root | Yes | .cursor/rules/*.mdc | Yes
Codex | ~/.codex/config.toml (user-level) | No | AGENTS.md | Yes
Replit | .replit, tokens in Secrets | Yes | AGENTS.md | Yes
Lovable | Settings UI, no file | No | AGENTS.md | No

## Team setup versus personal setup

Read the third column first. Cursor and Replit keep configuration in files that live in the project, so committing them makes the design route a team capability — a teammate clones the repo and inherits the same connection, without a setup document and without being told. That is a meaningful difference in practice, because setup documents are read once and then rot.

Codex sits at the other end. Its MCP configuration is user-level, in `~/.codex/config.toml`, which means it is per-person by construction. Nothing you commit will configure a colleague's Codex. If your team standardises on it, plan for the setup step to be repeated by everyone and to drift as people upgrade tools at different times.

Claude Code sits in the middle and is the most flexible of the three: you can add a server with `claude mcp add` for yourself, or commit the configuration so the project carries it. That flexibility is genuinely useful and also the reason two people on the same repo can end up with different servers connected without either noticing.

## Instructions files are not interchangeable

All five agents read a project instructions file, and it is the cheapest place to record how design reaches the project — where exports live, which server is connected, what the export format preserves. But the files behave differently enough that copying one into another's filename is not a migration.

- CLAUDE.md: Read by Claude Code. Keep it well under 200 lines. It competes with your prompt for attention, and a bloated one makes the agent worse rather than better informed.
- .cursor/rules/*.mdc: Cursor's format, and the most precise of the three: rules are glob-matched, so a rule can apply only inside `src/components/` and stay out of the way everywhere else. Use this for "reuse the existing components" instructions that would be noise at the repository level.
- AGENTS.md: The open format, read by Codex, Replit and Lovable. Broadest reach, no scoping — everything in it applies everywhere, all the time.

If you support more than one agent, write the durable facts once and keep the per-agent files thin. Duplication across three instructions files is how three files end up disagreeing.

## Lovable takes a different path

Lovable is the outlier in the table and the one most likely to break an assumed workflow. Figma's MCP server only accepts connections from clients in its catalogue, and Lovable is not in it — so the live connection route is simply unavailable.

The route instead is the Builder.io plugin: export the frame from Figma with the plugin and open the result in Lovable. Two things follow. First, it is a snapshot rather than a connection — change the design afterwards and nothing propagates; you re-export. Second, Auto Layout stops being best practice and becomes load-bearing, because the conversion uses it to infer structure. A frame with everything absolutely positioned converts into something no amount of prompting will straighten out. The Figma-side detail is in Figma to a coding agent.

## Replit and the token problem

Replit gets the team story right — configuration in `.replit`, travelling with the project — but that same property creates an obvious hazard. A committed configuration file with a bearer token in it is a committed credential. Tokens belong in Replit Secrets, referenced from the configuration rather than written into it.

This applies more broadly than Replit. Any MCP endpoint you connect an agent to should be scoped narrowly enough that a leaked token is an inconvenience rather than an incident: read-only where the agent has no reason to write, scoped to one project rather than an account, rate-limited, and revocable on its own without disturbing anything else.

## The verdict

If your priority is that everyone on the team inherits the same design route from a clone, Cursor is the cleanest, with Replit close behind for hosted work. If your priority is flexibility and depth of terminal workflow, Claude Code — with the configuration committed, so it behaves like Cursor's. Codex is excellent and quietly per-person; budget for that. Lovable is the only one where you have to redesign the workflow rather than the configuration.

But none of them enforces a design system. All five treat design context as guidance, which is the right default for a general-purpose tool. And more importantly, none of them carries your design decisions between sessions, and none of them carries them between repositories. Whichever you pick, that part is still yours to solve — and it is solved in the same place regardless of which row of the table you are in. Flowpoint takes the same view on the analytics side: our MCP server is the interface, and the data behind it stays fixed and yours.

## Test it

Clone your own repository into a fresh directory, as a teammate would, and open it with your agent. Ask it to build a screen from your design source without telling it anything about how design reaches this project. If it finds the route, your configuration travels. If it starts inventing, the route lives on your machine and not in the project — which is worth knowing before you write a setup document nobody reads.

## Frequently asked questions

### Which coding agents can connect to Figma's MCP server?

Claude Code, Cursor, Codex and Replit can. Lovable cannot — Figma's server only accepts connections from clients in its catalogue, and Lovable is not one of them; it uses the Builder.io plugin export instead.

### Does MCP configuration travel with a git repository?

It depends on the agent. Cursor keeps it in .cursor/mcp.json at the repo root and Replit in .replit, so both travel when committed. Codex keeps it user-level in ~/.codex/config.toml, so it does not. Claude Code can do either.

### What is the difference between CLAUDE.md and AGENTS.md?

CLAUDE.md is read by Claude Code; AGENTS.md is the open format read by Codex, Replit and Lovable. Cursor uses neither — it reads glob-matched .mdc rule files under .cursor/rules, which lets a rule apply only to specific directories.

---

# Your agent is not ignoring your design — it never got the rules

URL: https://flowpoint.ai/blog/design-files-vs-design-rules
Published: 2026-08-17
Tags: Design to code, AI coding agents, Workflow

Every handoff route sends what a design contains. None of them sends why. That missing half is small, writable in an afternoon, and the reason generated screens keep drifting off-brand.

## Geometry travels, reasoning does not

Set up any design handoff properly — a Figma Dev Mode connection, a structured Canva export, a Claude Design bundle — and you will find the same residue of dissatisfaction on the other side. The screen is right. The next screen is nearly right. The one after that has a heading size you have never used and an accent colour on an element that should not have one.

The instinct is to blame the model, and it is the wrong diagnosis. Every one of those routes transmits geometry: elements, positions, sizes, colours, sometimes component structure. None of them transmits reasoning. The agent received what the design contains and nothing at all about why — which values were deliberate, which were incidental, and what the rules are for a screen nobody has drawn.

## The two questions an export cannot answer

Concretely, there are two questions the agent has to answer to produce on-system work, and no export format answers either.

- Was this value intentional?: A colour bound to a variable and a colour someone typed in under deadline arrive identically. So do a heading in your type scale and a heading someone nudged two pixels. The agent reproduces both faithfully, which means it reproduces your mistakes with the same confidence as your system.
- What applies to screens that do not exist?: This is the larger one. A settings page, an empty state, a permissions error, a billing failure — nobody designs these first, and everybody needs them. There is no selection to send and no file to export. The agent has to infer, and it infers from the average of everything it has ever seen rather than from anything of yours.

## What a rules layer contains

The missing half is smaller than people expect. It is not a design system in the engineering sense — not components, not tokens, not tested and versioned code. It is the layer before that: the decisions an agent needs while it is building, written where it can read them.

- Colour roles, not hex codes: A hex code records what was used once. A role governs what happens next: this is the single accent, it appears on primary actions and active states and nothing else; this is the surface; this is the destructive state. Roles generalise to screens that do not exist yet, which is the entire point.
- Type ownership and the sizes that exist: Which face owns headings, which owns body, and the actual scale. State what is not in the scale too — the invented 19px heading between two real ones is one of the most common drift symptoms, and naming the boundary prevents it.
- Spacing and motion as numbers: The values, not adjectives. "Generous" and "snappy" are resolved differently by two sessions of the same model an hour apart. A spacing scale and a transition duration are among the cheapest things to write down and the most visible when they are wrong.
- A named audience: Microcopy register follows entirely from who is reading. "Technical buyers evaluating an on-premise tool" and "first-time users" produce different words for the same button. Name them once and the tone stops sliding between screens.
- A never list: Negative constraints do more work than everything above them combined. No gradients on surfaces. Never centre body copy. No emoji in product UI. Each one closes off an entire family of plausible-looking wrong answers before the agent goes anywhere near it — and unlike positive instructions, they cannot be satisfied halfway.

If you already have a mature component library, point the agent at your code — that is a better source of truth than any document, and it is executable. A rules layer is for what code cannot express: tone, audience, motion feel, the reasons behind the constraints, and the decisions that exist before there is a component to hold them.

## Where it has to live

Writing the rules down is the easy half. Where they live decides whether they keep working.

- In the prompt: Works once. Costs you the retyping every session, and the wording changes slightly each time — which is exactly how two screens end up on two systems. Taste that has to be re-typed every prompt is not a system, it is a habit with a failure rate.
- In a repository markdown file: A genuine improvement and free to try. It survives the session and travels with the code. It stops scaling at the second repository and breaks at the third client, because now there are four copies of the rules and they diverge quietly — nobody notices until a screen comes out on last quarter's palette.
- In a source the agent queries: One place the rules live, read on demand over the same MCP transport the agent already uses for everything else. Update it once and every connected project sees the change. The agent pulls only what the request needs rather than carrying the whole thing all session.

The third option is worth a note on cost, because the objection is usually context budget. A serialised set of design decisions is small — well under a couple of thousand tokens for most products, and only the relevant parts get pulled for a given request. That is a rounding error next to the base64-inlined HTML export some workflows are sending instead.

## What it does not fix

An agent follows a rules layer the way it follows any other instruction: usually, not religiously. You will still correct things. What changes is the baseline — the starting point moves from the average of the model's training data to something recognisably yours, and corrections become adjustments rather than rebuilds.

It also does not replace the design handoff. You still need the export or the connection or the bundle, because the rules describe every screen and the handoff describes this one. Two inputs, doing different jobs. The mechanics of the first are in how to export a UI design to a coding agent.

## Test it

Ask your agent, in a fresh session with no design attached, to build a settings page for your product. Do not describe the styling. Then compare it to a real screen from your product.

Check four things: the accent colour and what it landed on, the heading size, the spacing rhythm, and the tone of the microcopy. Every one of those that matches came from a rule the agent could read. Every one that does not is a decision that currently lives only in your head, or in a design file the agent was never going to open.

## Frequently asked questions

### Why does AI-generated UI look off-brand even with a good design handoff?

Because handoffs transmit geometry, not reasoning. The agent cannot tell an intentional design token from an incidental value, and it has nothing to consult for screens that were never designed — so it fills those gaps from the average of its training data.

### Is a markdown file in the repo enough to keep an agent on-brand?

For one repository, often yes. It stops scaling once you have several repositories or clients, because each gets its own copy and the copies diverge silently. At that point the rules want to live in one place the agent queries rather than in four files that disagree.

### How many tokens does it cost to give an agent design rules?

Very few. A serialised set of design decisions for a typical product runs to under a couple of thousand tokens, and a well-built source returns only the parts relevant to the request — far less than an inlined HTML export of a single screen.

### What is the difference between a design system and a design rules layer?

A design system is code — components and tokens, tested and versioned. A rules layer is the layer before that: colour roles, type ownership, motion feel, audience and constraints. If you have a mature component library, point the agent at your code; the rules layer covers what code cannot express.