Skip to main content
Most teams that come to Email Love already have a Figma email library. Templates, components, a type ramp, a palette, years of decisions baked into them. The question is never “should we start over”, it is “how much of this comes across, and what does it cost”. Two agent skills answer that. The first audits what you have without touching it. The second converts it. They are separate on purpose: the audit is a decision document you can act on without committing to anything.
Prefer this done for you, design review included? That is Email Love Enterprise onboarding. Email hello@emaillove.com.

​
The two phases

The audit report is required input to the converter. It carries the list of modules and what happens to each one, the brand foundations, how much of your file’s geometry is a specification worth preserving, the scale your file is drawn at where that applies, and the flags, so the conversion does not re-decide anything that was already settled. If you run the converter without an audit, it will ask you to do the audit first.

​
Your source file is read-only, throughout

Both phases treat your existing file as a source to read, never a place to work. The audit only inspects. The conversion screenshots, downloads assets, and builds everything in a separate target file, either one your team designates or a new one named for the customer. Nothing in your current library gets renamed, restructured, or deleted. If a migration goes sideways, your originals are exactly where they were.

​
Phase 1: the audit

The audit walks your file and produces one markdown report you can share internally. It surveys the file. Pages and what each holds, your local text styles (the type ramp with families, weights, and sizes), local paint styles and their naming, variable collections, spacing components, and a census of every candidate design with its width and height. Desktop and mobile twins of the same design get merged into one count, because in Email Love they become one frame with Mobile Styles overrides rather than two frames. It works out what your library actually reduces to. A finished email is not the unit that gets converted. The reusable blocks inside it are, and Email Love calls those modules: a hero, a copy block, a product row, a footer, the same handful turning up again in a different order each time. So the audit splits each design into modules, merges the repeats into one entry, names each one the way it should be named in your library, and reports that list. What the module is, which of your designs it appears in, and what happens to it in email. On a library where the pieces recur, that list is much shorter than the pile of designs you started with. In one migration we ran, six finished emails came out as nine distinct modules, so the work was building nine things once rather than rebuilding six emails. You still get a per-design view, for the times you want to ask what happens to one specific email, but it reads off the module list rather than competing with it. It says what happens to each module, in one of four verdicts:
  • (A) Live-text convertible. Auto-layout stacks of text, images, and buttons that map cleanly onto email structure. Text stays selectable in the sent email, which is best for deliverability and accessibility. Most modules should land here.
  • (B) Editable-image candidate. Design-rich compositions where text and imagery genuinely interleave. Email Love handles these deliberately: the design frame sits in a column with no MJML type name, and the exporter flattens it to a single hosted image at export while it stays fully editable in Figma. No rebuild needed. The cost is that the text inside is not live in the inbox, so it wants alt text and critical copy kept outside the image.
  • (C) Hybrid. Split the module: headline and body as live text, the rich visual region as an editable image. Reserved for blocks where copy and picture are one composited whole with no boundary to cut on, such as type set over a photographic collage where the lettering is part of the artwork. A photo that simply overlaps or bleeds past its block is not this, and is verdict A with a concession instead (see below). The test: if you can name the rectangle the image belongs in and the rectangle the text belongs in, it is an A. If you cannot, it is a C.
  • (D) Not emailable. Hover states, carousels, viewport-relative layouts, app UI. The report lists what would replace them.
A good audit does not over-classify toward images. Text over a single background photo stays live text, and sections support background images behind live columns, so “headline on a photo” is usually verdict A rather than B. A photo that overlaps or bleeds past its block is not a partial conversion either. Source designs do this constantly: an image pushing in from the right behind body copy, a photo cropped by the edge of a colored band with text sitting beside it. Figma does it with layering and absolute position, and email has neither, so the overlap itself cannot come across. The substitute is settled, and the audit applies it by default rather than arguing it module by module: the block gets rebuilt as two columns side by side, the image in one and the text in the other, in the order the design reads. The image stops at its column edge instead of running past it. That is the entire loss, and it gets named as a concession like any other. What you keep is the part that matters, because the text stays live: selectable in the inbox, readable by a screen reader, still working in dark mode. On a phone the columns stack, so the image sits above the copy, which is a normal email layout and arguably better than a bleed you would have had to give up on a small screen anyway. Filing these as image work would trade all of that for an effect. A module can convert cleanly and still cost you one design decision. Sometimes everything about it works as live text except a single effect email has no way to reproduce: a full-bleed treatment that has to stop at the content box, a blur, a blend mode. That is not a partial conversion, and filing it as one makes the news sound worse than it is while burying the part that actually needs a person. So the report leaves the module in the clean column and names the concession beside it, with what is lost and the closest email-safe substitute we would use, then repeats it in the flags list for your designer to accept or reject before anything gets built. Every cleanly converting module either says “no concession” or names one, so silence is never the answer. Your library does not need to be well organised for this to work. This is worth saying plainly, because it is the thing people apologise for before they send us a file. A tidy email-native library and a messy old one both migrate. What changes is which parts of the file we carry across. So the audit says which kind of file you have, and it is one of three:
  • Your geometry is the spec. The file is already drawn at email widths, with real text styles, components, and margins that repeat because somebody chose them. We preserve your widths, margins, type sizes, and spacing, and any deviation gets a reason written next to it.
  • Some of it is deliberate and some is not. The normal shape of a real library. We keep what the file proves (the same measurement in at least three places, identical rather than similar) and standardise the rest, flagging each call so you can see which numbers came from your file and which came from us.
  • The file is a reference, not a spec. No particular width, no styles, margins that were eyeballed one at a time. Then we take your brand, your copy, and your module structure, and build the geometry to email standards: 600 wide, body copy at 16, spacing in multiples of 8, one content width for every module. Your emails still look like your brand. They just get margins somebody chose.
That last one is the case people worry about, and it is the easy one. Preserving a margin nobody decided on only reproduces the guess with more precision than it was made with. So we do not, and the report says the geometry is ours, in as many words, so nobody on either side later “corrects” the new library back toward the old file. It extracts your brand foundations. Each of your text styles mapped to an email-safe equivalent, using your own fallback choices when your file already has a fallbacks page. Your palette, plus a proposed set of the six Email Love theme colors drawn from it, marked as a proposal for your designer to confirm. Your spacing scale, your button styles, and the width your email version gets built at. If your file is drawn larger than a real email, which is normal for mockups made to present rather than to send, and its proportions were deliberate, the audit works out the scale it is drawn at, tells you which reading of it it trusts, and converts every number down to email size for you. Where the proportions were not deliberate, there is no scale to work out and the standards above are what you get instead. It flags what a human should look at. Fonts that are not licensed or available for email, component masters living in a library file nobody shared, inconsistent widths, empty pages, accessibility risks from image-heavy modules. A missing library file is the single most common blocker an audit surfaces, which is why it asks about that up front. It estimates effort. Counts per verdict, a size per module, and a total in designer-days as a range. The counts are over distinct modules, which is why they usually come in below what a count of your designs would suggest. The report says plainly that estimates firm up after the first converted batch, because they do.

​
Phase 2 and 3: the conversion

Conversion runs in two phases, foundations once and then modules in batches. Foundations builds the scaffold every batch depends on: your type ramp recreated as text styles on the email-safe fallbacks, your buttons rebuilt as proper email components rather than app-style nested instances, your spacing scale, your logo and recurring imagery round-tripped into the target file, and one root email frame so batch 1 has somewhere to be seen in context. It also lays the file out the same way every time. The page structure is fixed rather than invented per project, because the real test of a design system file is whether someone who did not build it can open it and get to work. What you get:
  • A cover with the brand name, the version, and the width the system is built at, so nobody has to ask which email width these modules assume.
  • A getting started page: how to use a module, how to change its copy and images, and where to look when an export does not come out the way you expected.
  • Foundations as a real token sheet. Your colours and spacing become Figma variables, with plain named values underneath and the semantic names your components actually point at on top, so changing a brand colour is one edit instead of forty.
  • A type page as a specimen sheet. Every style shown as a line of real text with its family, weight, and size printed beside it, so you can check the whole ramp by eye.
  • One page per module category, heroes, footers, product rows, taken from the audit’s module list in the order the audit put them in, with divider pages grouping the foundations, the components, and the templates.
Module batches work down the audit’s module list a handful at a time, one component per module, so a module that showed up in six of your designs gets built once. For each module: screenshot the source, run it through the same conversion engine that powers AI Import, transcribe the returned structure into the target file, merge the mobile twin’s intentional differences into Mobile Styles data, turn it into a component with properties for the parts a marketer will actually change, then verify the rebuild against the source screenshot. Then a design review gates the next batch. This is not ceremony. The first batch is where the theme colors get confirmed, where the type mapping meets real copy, and where anyone notices that a verdict was wrong. Converting a whole library in one unreviewed pass is how you end up redoing all of it.

​
How long this takes

There are really two questions here, and they have very different answers. How long until you see something is minutes. How long for your whole library is a project measured in sessions. The audit is quick. It reads and creates nothing, so it finishes in minutes, scaling with the size of your library rather than its complexity. A hundred designs takes longer to walk than twenty, but it is still something you kick off and wait on rather than something you schedule around. That is the other reason to always start here. It costs almost nothing to find out what you are in for. Foundations is a single pass, in the same range as one batch of modules. It happens once, and everything after it is faster for having it. A first batch of about five modules takes tens of minutes. That is the number worth planning around, because it is the first time you see your own designs rebuilt as real email structure and can judge whether the result is right. On an unstructured source file, expect noticeably longer. A full library of a hundred modules or more takes multiple sessions. Not an afternoon. This is exactly why the work is batched with a design review in between: spreading it out is the design, not a limitation. In practice your team’s review time between batches, not the conversion itself, is what sets the calendar. Treat all of this as what we have seen rather than a promise. Your file, your library size, and how much judgment each module needs all move the number.

​
What actually drives the time

Not the AI. The conversion engine that turns a design into email structure takes seconds to about half a minute per design, and it is never the bottleneck. Almost all of the time is round trips to Figma. Every node the agent creates or reads is a separate call, and a module is made of nodes. So the node count predicts the time better than how complicated a module looks: a forty-node module takes many times longer than a six-node one, even when the two look about equally busy on the canvas. The other big factor is the shape of your source. A file that is already email-native, frames at 600 or 640 with auto layout in place, converts far faster than an unstructured one built from groups, absolute positioning, or a scaled-up mockup. On a real unstructured file we saw roughly three times the time per module, because before the agent can rebuild anything it has to work out where each module begins and ends. The audit tells you which kind of file you have, which is one more reason to run it first.

​
What a module actually is

Worth knowing before you review a batch, because it is the thing that most often needs fixing. A module is one reusable block, so its shape is an mj-wrapper component: the wrapper itself is the component, its layer name is the module name, and it carries no email-template marker anywhere in its tree. An email template is the other shape, a root frame with wrapper components stacked inside it. Foundations builds exactly one of those, for context, and it is not a starting point for a module. The distinction is not stylistic. The plugin decides which one you uploaded by looking at the top node of your selection, and only a wrapper gets stored as a reusable block with the machine-readable component data behind it. A module built as a small email uploads without complaining and then behaves like an email, which is the kind of thing nobody notices until months later. Modules also carry no theme color keys. Those live on the email that contains them. When a batch is approved, the components go into the plugin the same way any component does: pick the design system, open the section, select the wrapper components on the canvas, and click Upload. A multi-selection of wrappers uploads as one batch, which is how you get a whole approved batch in without clicking through it one at a time. See Creating and Managing Design Systems.

​
Running it yourself

Choose your agent below. Claude installs separate audit and converter skills. Codex installs one Email Love plugin that contains the complete migration workflow.
Install the audit on its own if you only want to scope the job. Inside an interactive claude session, the same commands work as /plugin slash commands.
The audit needs only read access to your file. The conversion also needs the Email Love plugin installed in the target file, and it uses your local shell to hold each module’s screenshot and returned structure.

​
What to expect

  • Start with the audit, always. It is read-only and it answers the question everyone actually has, which is what this costs.
  • Your library is probably smaller than it looks. The report sizes the job by distinct modules rather than by finished designs, and where the same pieces recur that number lands well below the count of designs you walked in with.
  • The audit is shareable. It is written for both your team and ours, so it works as the scoping document for an Enterprise onboarding conversation.
  • Numbers in the report come from real reads. Where the audit sampled instead of walking everything, it says so.
  • Verdicts can change on contact. A module classified A that turns out to be layered art becomes C during conversion, with the reason recorded in the batch report.
  • Two things want a yes before conversion starts. The scale the system gets built at, and each named concession. Both change every module built from them, so agreeing on them up front is cheaper than redoing a batch.
  • A messy file is not a blocker. The audit decides whether your geometry is a specification we carry across or a reference we rebuild from at email standards, and it says which, so you can overrule it if you disagree.
  • Don’t skip the design review between batches. It exists because batch 1 always surfaces something.
  • Plan a migration as a project, not an afternoon. The audit is minutes and a first batch is tens of minutes, but a full library runs across several sessions with review in between.
  • Saving modules into a design system needs a paid plan. The audit and the conversion both work on any plan, but the Upload control in the plugin’s Assets panel only appears for subscribers, so that final step is where a free account stops.

​
Need help?

Email hello@emaillove.com and we’ll respond within a business day.