Update to Email Love

{
  "name": "email-love-design-system-migration",
  "description": "Audit and migrate an entire legacy email design system or library into an Email Love Figma design system. Use when the user asks to assess migration readiness, inventory legacy email modules, determine source fidelity or scale, create Email Love foundations, convert a legacy library in batches, or migrate templates from Figma, a local folder, cloud storage, or a supported ESP. The source remains read-only and all conversion happens in a separate target Figma file. Do not use for building one campaign email; use email-love-figma-builder for that.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 494
    },
    {
      "relative_path": "references/audit.md",
      "size_in_bytes": 61675
    },
    {
      "relative_path": "references/conversion-overview.md",
      "size_in_bytes": 8418
    },
    {
      "relative_path": "references/foundations.md",
      "size_in_bytes": 46969
    },
    {
      "relative_path": "references/module-conversion.md",
      "size_in_bytes": 63988
    },
    {
      "relative_path": "references/progress.md",
      "size_in_bytes": 13460
    },
    {
      "relative_path": "references/render-components-validation.md",
      "size_in_bytes": 19924
    },
    {
      "relative_path": "references/render-geometry.md",
      "size_in_bytes": 46948
    },
    {
      "relative_path": "references/render-nodes.md",
      "size_in_bytes": 43284
    },
    {
      "relative_path": "references/sources/activecampaign.md",
      "size_in_bytes": 1066
    },
    {
      "relative_path": "references/sources/brevo.md",
      "size_in_bytes": 1250
    },
    {
      "relative_path": "references/sources/customer-io.md",
      "size_in_bytes": 2734
    },
    {
      "relative_path": "references/sources/google-drive.md",
      "size_in_bytes": 1599
    },
    {
      "relative_path": "references/sources/hubspot.md",
      "size_in_bytes": 1211
    },
    {
      "relative_path": "references/sources/iterable.md",
      "size_in_bytes": 1199
    },
    {
      "relative_path": "references/sources/kit.md",
      "size_in_bytes": 994
    },
    {
      "relative_path": "references/sources/klaviyo.md",
      "size_in_bytes": 2202
    },
    {
      "relative_path": "references/sources/local-folder.md",
      "size_in_bytes": 2340
    },
    {
      "relative_path": "references/sources/marketo.md",
      "size_in_bytes": 2695
    },
    {
      "relative_path": "references/sources/omnisend.md",
      "size_in_bytes": 1019
    },
    {
      "relative_path": "references/sources/sharepoint.md",
      "size_in_bytes": 1312
    }
  ],
  "skill_md_contents": "---\nname: email-love-design-system-migration\ndescription: Audit and migrate an entire legacy email design system or library into an Email Love Figma design system. Use when the user asks to assess migration readiness, inventory legacy email modules, determine source fidelity or scale, create Email Love foundations, convert a legacy library in batches, or migrate templates from Figma, a local folder, cloud storage, or a supported ESP. The source remains read-only and all conversion happens in a separate target Figma file. Do not use for building one campaign email; use email-love-figma-builder for that.\n---\n\n# Email Love Design System Migration\n\nAudit a legacy email library from Figma, files, cloud storage, or a supported ESP, establish\nits trustworthy foundations, and convert it into a reviewable Email Love design system in a\nseparate Figma target file.\n\n## Non-negotiable boundaries\n\n- Keep every source read-only at all times. Never edit a source Figma file, local folder,\n  cloud folder, ESP template, campaign, automation, or message.\n- Build only in a separate target file.\n- Never convert an unaudited library.\n- Never convert the entire library in one unreviewed pass.\n- Never invent Email Love structure from visual intuition. Use the design-converter worker\n  and the packaged render rules.\n- Never start conversion while required human gates remain unresolved.\n- Never present an individual module as a complete design system.\n\n## Which model to run this with\n\nIf your environment lets you choose a model tier or reasoning-effort setting, use your\nstrongest available option for this skill. A migration runs once per customer and holds a\nlarge rule set at once (the render references alone are tens of thousands of tokens); a\ndropped rule becomes a component that silently breaks on export later, for someone who was\nnot in this conversation to catch it. The extra cost is small next to the cost of getting\nit wrong. This is a different budget from the routine campaign builds a customer does\nafterward against an already-verified design system, where a faster model is usually fine.\n\n## Before doing anything\n\n1. Identify where the source emails live and select the source adapter in Phase 0 (ask only when the request has not already named or linked the source).\n2. For a Figma source, confirm the official remote Figma MCP exposes `get_metadata` and\n   `get_screenshot`. For conversion, also confirm it exposes `use_figma`.\n3. Before calling `use_figma`, read the Figma MCP's current `figma-use` skill or equivalent\n   instructions in full.\n4. If `use_figma` is missing, limit work to the read-only audit and a precise migration\n   report. Do not promise conversion.\n5. Confirm whether the user wants:\n   - audit only;\n   - foundations only after an accepted audit;\n   - a specific conversion batch; or\n   - the complete staged migration.\n6. Obtain the source link, path, folder, or account scope required by the selected adapter.\n   For conversion, obtain or create a separate target Figma file link.\n\nDo not ask the user to disable the sandbox or bypass all approvals. Use normal tool\napprovals. For unattended work, recommend a trusted isolated environment with narrowly\nscoped permissions.\n\n## Load references by phase\n\nRead references completely before acting in the corresponding phase:\n\n- **Audit:** [audit.md](references/audit.md)\n- **The selected non-Figma source only:** load its adapter from\n  [`references/sources/`](references/sources/)\n- **Any run longer than a couple of minutes:** [progress.md](references/progress.md)\n- **Conversion entry and gates:** [conversion-overview.md](references/conversion-overview.md)\n- **Foundations:** [foundations.md](references/foundations.md)\n- **Module batches:** [module-conversion.md](references/module-conversion.md)\n- **Before any module transcription, all three render references:**\n  - [render-geometry.md](references/render-geometry.md)\n  - [render-nodes.md](references/render-nodes.md)\n  - [render-components-validation.md](references/render-components-validation.md)\n\nThe render references are deliberately split by topic. Search them by rule number (`R0` to\n`R9`) or exact tag when re-checking a rule, but read all three completely before the first\nmodule transcription in a run.\n\n## Phase 0: Pick the source\n\nAsk only when the source is missing or genuinely ambiguous. When the request already names or\nlinks the source - a pasted Figma link, a folder path, \"our Klaviyo templates\" - that IS the\nanswer: confirm it in one line and select its adapter without presenting the menu. Otherwise\nask this once before scoping the audit:\n\n> Where are the emails you want to migrate?\n> (a) Figma, (b) local folder, (c) Klaviyo, (d) Marketo, (e) Customer.io,\n> (f) Google Drive, (g) SharePoint, (h) Brevo, (i) Kit, (j) ActiveCampaign,\n> (k) Iterable, (l) Omnisend, or (m) HubSpot?\n\nThe answer selects exactly one route:\n\n| Choice | Source | Adapter |\n| --- | --- | --- |\n| a | Figma | Use the audit reference directly |\n| b | Local folder | [local-folder.md](references/sources/local-folder.md) |\n| c | Klaviyo | [klaviyo.md](references/sources/klaviyo.md) |\n| d | Marketo | [marketo.md](references/sources/marketo.md) |\n| e | Customer.io | [customer-io.md](references/sources/customer-io.md) |\n| f | Google Drive | [google-drive.md](references/sources/google-drive.md) |\n| g | SharePoint | [sharepoint.md](references/sources/sharepoint.md) |\n| h | Brevo | [brevo.md](references/sources/brevo.md) |\n| i | Kit | [kit.md](references/sources/kit.md) |\n| j | ActiveCampaign | [activecampaign.md](references/sources/activecampaign.md) |\n| k | Iterable | [iterable.md](references/sources/iterable.md) |\n| l | Omnisend | [omnisend.md](references/sources/omnisend.md) |\n| m | HubSpot | [hubspot.md](references/sources/hubspot.md) |\n\nDo not infer the source silently. Recommend Figma when it is available because components,\nstyles, variables, and cross-design reuse produce the richest audit. Then follow the source\nthe customer actually has. Load only the selected adapter, completely, before discovery.\n\n## Phase 1: Audit\n\nRead the audit reference, then:\n\n1. Scope every source item included using the selected adapter's Discover procedure.\n2. For Figma, inventory pages, frames, components, component sets, styles, variables, email\n   widths, mobile twins, and repeated modules with read-only calls. For other sources, use the\n   adapter's audit-step adaptations.\n3. Classify source fidelity:\n   - **AUTHORITATIVE:** geometry is a deliberate specification.\n   - **PARTIAL:** preserve repeated deliberate values and standardize inconsistent ones.\n   - **REFERENCE ONLY:** preserve brand, copy, and structure, but build geometry to email\n     standards.\n4. For AUTHORITATIVE and PARTIAL sources, derive both width and type evidence, select one\n   scale factor, apply it consistently, and prove that type ratios survive.\n5. Split designs into reusable modules before classifying them.\n6. Record the canonical body width, content width, type ramp, spacing, colors, radii,\n   buttons, images, and fallbacks.\n7. Produce the migration report in the exact structure defined in the audit reference.\n\nEvery reported count must come from actual reads. Every judgment must name its evidence.\n\n## Human gate after the audit\n\nDo not begin conversion until the user confirms:\n\n- the migration scope;\n- the source-fidelity tier when it involved judgment;\n- the scale factor for AUTHORITATIVE or PARTIAL sources;\n- any blocking flag affecting how modules will be built.\n\nA missing component source file blocks conversion. A REFERENCE ONLY source does not need a\nfabricated scale factor.\n\n## Phase 2: Foundations\n\nRead the conversion overview and foundations references. Build foundations once per\ncustomer, before any module:\n\n- prescribed page structure;\n- cover and getting-started guidance;\n- two-tier primitive and semantic color variables;\n- spacing and radius variables;\n- type specimen and text styles;\n- button foundations;\n- email-template proof root;\n- target body and content widths;\n- source-specific image and font handling.\n\nBind component fills to semantic variables, never primitives or raw hex. Keep plugin-data\ntheme keys literal because variables cannot bind them.\n\nRun the complete foundations checklist before approving batch 1. Do not use module\nconversion to patch missing foundations.\n\n## Phase 3: Module conversion\n\nRead the module-conversion reference and all render references.\n\n1. Before the first module, establish how the batch checks will run. Probe the Email Love MCP\n   for `emaillove_export_figma`. When present, use it with `operationType: \"preview\"` for a\n   quota-free headless export and use its token with `emaillove_preview_email`; no plugin click\n   is needed for covered core tags. The Email Love MCP (server name `emaillove`) may be\n   connected separately from this skill's install, so when its tools are absent, determine\n   which case applies before prescribing setup: the server may be UNCONFIGURED (a directory\n   or skills-only install carries no MCP configuration; add it with `codex mcp add emaillove\n   --url https://mcp.emaillove.com/mcp`), UNAUTHORIZED (configured but not signed in; run\n   `codex mcp login emaillove`, and explain that the sign-in screen is Email Love's normal\n   account flow, the same sign-in the Figma plugin uses), or UNAVAILABLE (configured and\n   authorized but not responding). Start a fresh task after any change so the tools appear.\n   An unavailable renderer means verification is deferred, not passed. Do not confuse this server with the Email Love inspiration/library MCP;\n   the two are not interchangeable. If the tool raises a CoverageError for `mj-hero`,\n   `mj-social`, `mj-navbar`, or `mj-table`, ask a human to run the paid-seat plugin Export and\n   maintain the Deferred verification list when no human is available.\n2. Whatever the library size, start with a proof batch of at most four modules covering the\n   source's relevant risk classes. Do not start later batches until every proof module\n   passes production desktop and mobile checks and the user accepts the proof batch; if\n   production rendering is unavailable, stop after preparing the proof and report deferred\n   verification (a user approval does not substitute for missing render evidence). After\n   that gate, use batches of roughly five modules so a review can stop a repeated defect\n   early; a small library may finish in a single further batch.\n3. Before the first write, name the batch and its module count and give a rough estimate, and\n   freeze a compact batch Fact Pack carrying only what this batch can be wrong about: the\n   structural authority (source node tree, or supplied/ESP HTML, per the audit), the visual\n   authority (approved comps or source renders; defect screenshots are symptoms), the tier /\n   email width / content width / scale factor from the audit, one line per module mapping its\n   inventory row to the source ref actually converted from, and an `Unknown or pending` list.\n   Do not start writing while that list holds anything that can change what you build; evidence\n   arriving mid-batch that contradicts the Fact Pack stops the batch until it is re-frozen.\n   Approvals stay conversational and scoped to the batch: the design-review gate after each\n   batch is one approval for one batch, and a user request that already clearly authorizes\n   exactly this batch is that approval.\n4. For each module:\n   - read its audit row and build constraints;\n   - fetch or screenshot the source item at the target email width using its adapter;\n   - send only that customer's source render to the converter;\n   - save the returned JSON;\n   - transcribe according to the render references;\n   - apply the library's foundations and canonical content width;\n   - repair known worker limitations;\n   - create a reusable `mj-wrapper` component with no `mainFrame` marker;\n   - add customer-facing TEXT properties by default, while keeping boilerplate and\n     link-bearing text unbound; add BOOLEAN and INSTANCE_SWAP properties only from evidence;\n   - verify it with one compact read-back pass and one desktop screenshot.\n5. After provisional upload, run the mobile render and export sniff once for the batch, or\n   add specific outstanding checks to the Deferred verification list.\n6. Stop after the batch report for human review.\n7. Continue only after the batch is accepted.\n\nNever send a competitor email or Email Love inspiration preview to the converter.\n\n## Progress contract\n\nFollow the exact audit, foundations, batch, stopping, and resumable-state contract in\n`progress.md`.\n\nAt the start, state the phase, item count, named items, and estimate.\n\nFor audit work, report only meaningful completed units such as pages or audit stages. For\nconversion, report after each finished module:\n\n> Batch 2, module 3 of 5 done, 60 percent: Testimonial, quote led.\n\nBefore every converter request, say that the conversion may take several seconds to roughly\nhalf a minute and that transcription is the longer step. When retrying with `recache=1` or\nafter a trivial response, say so immediately.\n\nRevise estimates at the next module boundary when pace changes materially.\n\n## Verification\n\nUse the phase checklist and R9 from the references. At minimum verify:\n\n- source file unchanged;\n- source account, folder, and templates unchanged for non-Figma adapters;\n- every audit inventory row contains a source `T/I` content census;\n- prescribed target pages present in the correct order;\n- foundations and semantic bindings intact;\n- every text style name matches its read-back value, including weight;\n- one canonical body width and content width;\n- module root is a direct-page-child COMPONENT tagged `mj-wrapper`;\n- no `nodeType` exists anywhere in a module tree;\n- every created node has the exact plugin tag and friendly display name;\n- every frame is vertically HUG except `mj-spacer`;\n- fixed widths are documented load-bearing cases;\n- pinned text widths include fallback slack;\n- images use source-node renders with preserved aspect ratios;\n- source and build pass Group 0 parity for text, images, alignment, and band fills;\n- image assets match the source identity, icon set, luminance context, and sprite crop;\n- overlaps use the Two Column Swap;\n- component-property bindings were read back;\n- every customer-facing text node is reachable through a module-root TEXT property except\n  boilerplate and link-bearing text;\n- no `mj-group` carries its own fill;\n- semantic fill bindings use the `.boundVariables?.color` predicate;\n- text-on-background contrast failures below 3.0 are reported without silently changing brand colors;\n- one fresh screenshot per module matches the accepted fidelity tier;\n- the batch mobile render and export sniff passed, or every outstanding check appears in the\n  Deferred verification list;\n- the batch contains no unreviewed modules beyond its declared scope.\n\nFix failures before presenting a batch.\n\n## Final handoff\n\nDeliver:\n\n- the audit and accepted human decisions;\n- foundations created;\n- modules converted by batch;\n- concessions and placeholders;\n- categories and component properties;\n- known limitations;\n- verification results;\n- the exact Email Love plugin upload sequence;\n- a recommendation to assemble one real sample email, export it, and send an inbox test.\n\nNever use an em dash in module copy, Figma layer names, or plugin-data values.\n"
}