Update to Email Love

{
  "name": "email-love-figma-builder",
  "description": "Build export-ready marketing and lifecycle emails inside Figma using Email Love components or the Email Love design-converter workflow. Use whenever the user asks to create, assemble, draft, convert, or build an email or email campaign in Figma; mentions Email Love, email design systems, mj-wrapper frames, ESP export, or AI Import; shares an email campaign brief with a Figma file; or asks to turn an existing email or Figma comp into an exportable email. Supports both customers with an existing Email Love design system and customers creating their first email without one. Do not use for migrating an entire legacy email design system; use email-love-design-system-migration for that.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 457
    },
    {
      "relative_path": "references/path-a.md",
      "size_in_bytes": 10458
    },
    {
      "relative_path": "references/path-b.md",
      "size_in_bytes": 23306
    },
    {
      "relative_path": "references/progress.md",
      "size_in_bytes": 9336
    },
    {
      "relative_path": "references/render-components-validation.md",
      "size_in_bytes": 17736
    },
    {
      "relative_path": "references/render-geometry.md",
      "size_in_bytes": 38960
    },
    {
      "relative_path": "references/render-nodes.md",
      "size_in_bytes": 34999
    },
    {
      "relative_path": "references/shared-rules.md",
      "size_in_bytes": 15990
    }
  ],
  "skill_md_contents": "---\nname: email-love-figma-builder\ndescription: Build export-ready marketing and lifecycle emails inside Figma using Email Love components or the Email Love design-converter workflow. Use whenever the user asks to create, assemble, draft, convert, or build an email or email campaign in Figma; mentions Email Love, email design systems, mj-wrapper frames, ESP export, or AI Import; shares an email campaign brief with a Figma file; or asks to turn an existing email or Figma comp into an exportable email. Supports both customers with an existing Email Love design system and customers creating their first email without one. Do not use for migrating an entire legacy email design system; use email-love-design-system-migration for that.\n---\n\n# Email Love Figma Builder\n\nBuild real, export-ready Email Love emails in the user's Figma file. Treat the underlying\nEmail Love structure as production code: canvas appearance alone does not prove that the\nemail will export.\n\n## Non-negotiable rule\n\nNever invent Email Love structure from memory.\n\nStructure comes from exactly two places:\n\n- **Path A:** instances of published components from the customer's Email Love design system.\n- **Path B:** measured conversion output returned by `emaillove_convert_design` for a\n  customer-owned Figma source when that MCP tool is available, otherwise MJML JSON from the\n  Email Love design-converter worker. Transcribe either result according to the packaged render\n  references.\n\nThe only structure created without either source is an empty email root and, when explicitly\nrequired, the narrowly defined `mj-raw` ESP token block. If neither path can produce a\nsection, stop and ask the user.\n\n## Which model to run this with\n\nThe two paths carry very different risk, so if your environment lets you choose a model tier\nor reasoning-effort setting, they deserve different budgets.\n\n**Path B, and the design-system-migration skill, deserve your strongest available model.** That\nwork holds a large rule set at once (the render references alone run tens of thousands of\ntokens) and a dropped rule becomes a component that silently breaks on export later, for\nsomeone who was not in this conversation to catch it. This is also work a customer does once,\nnot daily, so the extra cost is small next to the cost of getting it wrong.\n\n**Path A, once a design system is already synced and verified, is a smaller job.** Instance a\ncomponent, load its font, set text, done. A faster or lower-effort model handles routine\ncampaign builds reliably here, because mistakes are cheap and obvious: wrong copy in a button\nis visible the moment you look at it.\n\n## Before doing anything\n\n1. Confirm the official remote Figma MCP exposes `use_figma`, `get_metadata`, and\n   `get_screenshot`.\n2. Before calling `use_figma`, read the Figma MCP's current `figma-use` skill or equivalent\n   instructions in full.\n3. If `use_figma` is missing, say that the connection is read-only and do not promise a\n   canvas build. Offer:\n   - an email plan with copy and subject lines; or\n   - for Path B, a converter-assisted handoff where the user pastes the render into Figma\n     and runs AI Import in the Email Love plugin.\n4. Confirm the Email Love plugin is installed. Path A also requires a synced Email Love\n   design system.\n5. Check whether the Email Love MCP tools (`emaillove_convert_design`,\n   `emaillove_export_figma`, `emaillove_preview_email`) are available, and tell the user in\n   one line which of Figma writing, conversion, and export verification this session\n   actually has. When they are absent, distinguish an unconfigured server, one awaiting\n   authorization, and unavailable tools before prescribing a remedy; a skills-only install\n   carries no MCP configuration, so never send it straight to a login command.\n6. Treat a request to audit or migrate a whole legacy library as a different job. Use\n   `$email-love-design-system-migration`.\n\nDo not ask the user to disable the sandbox or bypass all approvals. Work through normal\nFigma tool approvals. For unattended operation, recommend a trusted isolated environment\nwith narrowly scoped permissions.\n\n## Load only the references required for the chosen path\n\nBefore any canvas write, always read:\n\n- [shared-rules.md](references/shared-rules.md)\n- [progress.md](references/progress.md)\n\nThen read:\n\n- **Path A:** [path-a.md](references/path-a.md)\n- **Path B:** [path-b.md](references/path-b.md), then all three render references before\n  transcription:\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- **Path A gap-fill using Path B:** read the Path B and render references before creating\n  the missing module.\n\nThe render references are deliberately split by topic. Search them by rule number (`R0` to\n`R9`) or exact tag (`mj-button`, `mj-group`, `mj-image`) when re-checking a rule, but read\nall three completely before transcribing converter output.\n\n## Step 1: Collect the brief\n\nDo not re-ask facts the user already supplied. Collect the missing essentials in one compact\nround:\n\n1. What email or sequence is this?\n2. What is the single primary CTA and its destination?\n3. What factual content must appear: offer, dates, products, proof, and source links?\n4. What is the Figma file link?\n\nFor sequences, also collect timing or trigger and the job of each email. For lifecycle\nemails, establish what the recipient just did. For multi-brand files, identify the brand.\n\nUse choice-shaped questions when an interactive question tool is available. Otherwise use\nlettered choices so the user can answer in one line. Ask at most two rounds, then proceed\nwith sensible assumptions and report them.\n\nNever invent statistics, dates, prices, legal language, addresses, or URLs. Mark unresolved\nfacts as placeholders.\n\n## Step 2: Use inspiration only when it helps\n\nWhen the user names a reference brand, the brief is thin, or the request is a sequence,\nsearch for Email Love inspiration tools such as `search_emails`, `fetch_email`,\n`get_brand_insights`, `list_journeys`, or `get_journey`.\n\nUse inspiration for:\n\n- section rhythm;\n- subject-line patterns;\n- offer framing;\n- tone;\n- sequence pacing.\n\nNever copy another brand's copy, convert a competitor preview, or send an Email Love library\npreview to the design converter. Path B input must be the customer's own material or a comp\ncreated for them.\n\nIf inspiration was explicitly requested but the tools are missing, say so before building\nand offer to continue using general best practice.\n\n## Step 3: Choose the path by checking\n\n1. If Email Love account tools are available, list brands, components, and templates.\n2. Otherwise inspect every relevant Figma page for `COMPONENT` and `COMPONENT_SET` nodes,\n   existing Email Love email roots, and library conventions.\n3. Route:\n   - relevant components exist: Path A;\n   - no design system exists: Path B;\n   - partial library: Path A for matching sections and Path B only for confirmed gaps.\n\n**Scope escalation is a reroute, not a bigger build.** If the request expands into a whole\nlibrary, foundations, variables, tokens, or multiple component categories, stop the builder\nworkflow and route to `email-love-design-system-migration`. Do not continue one module at a\ntime under this skill; a library approached as iterative email building skips the audit, the\nproof batch, and the batch gates that exist precisely for library-scale work. When reusable\nmodules were created or repaired during a build and the `email-love-figma-quality-gates`\nskill is installed, offer it as an independent acceptance pass at hand-off.\n\nTell the user the chosen path and why before the first canvas write.\n\n## Step 4: Establish the section plan and estimate\n\nFollow the exact progress and stop contract in `progress.md`.\n\nBefore writing, name every planned section and give a rough range:\n\n> Path A, 7 sections: preheader, header, hero, proof, feature list, CTA, footer. Roughly 6\n> to 9 minutes.\n\nThat section count is the denominator for every progress update.\n\nFor a sequence use two counters:\n\n> Email 2 of 4, section 3 of 7 done, 43 percent: hero.\n\nReport progress only:\n\n- before the first write;\n- after each complete section;\n- immediately before each Path B converter request;\n- when retrying a trivial or failed converter response;\n- at completion.\n\nEach section update must include the count, percentage, section name, and a revised estimate\nwhen actual pace differs materially.\n\n## Step 5: Build incrementally\n\n- Use one `setCurrentPageAsync` per `use_figma` call.\n- Write in small structural batches.\n- Read geometry writes back immediately.\n- Check metadata or a screenshot after every structural step.\n- Never detach an instance.\n- Never add, delete, reparent, retag, rename, or restructure layers inside a Path A instance.\n- Preserve the file's pages, order, variables, styles, tokens, breakpoints, widths, and\n  fonts.\n- Use exactly one visible primary CTA button unless the user explicitly asks otherwise.\n- Leave unknown final URLs unset rather than writing `#`.\n- Use flat gray placeholders at the correct dimensions for missing imagery and report them.\n- Place multiple emails side by side for review.\n\nOn Path B, save the converter JSON before transcription and treat it as the stable input.\nApply every repair defined in the Path B reference: pills, groups, placeholder images,\nfoundation drift, unsupported tags, and Two Column Swap detection.\n\n## Step 6: Verify before presenting\n\nRun the relevant checklist from the packaged references, not a remembered version.\n\nAlways verify:\n\n- the root has the intended email or module shape;\n- every Path A section is an intact component instance except a valid raw footer;\n- every Path B node is tagged and every leaf pair is complete;\n- every frame created is vertically HUG except an intentional `mj-spacer`;\n- fixed widths occur only in documented load-bearing cases;\n- both auto-layout alignment axes match, except the documented multi-column top-align\n  case (primary MIN with counter on the content's horizontal alignment);\n- pinned text widths include font fallback slack;\n- all vertical gaps are padding paid by one side only;\n- source images use rendered crops with preserved aspect ratios;\n- overlaps became the documented Two Column Swap;\n- all nodes intended for export are visible;\n- there is exactly one visible CTA unless requested otherwise;\n- the file's page list, variables, and styles remain unchanged.\n\nTake a fresh screenshot of every email and inspect for clipped text, overlaps, inconsistent\nspacing, missing content, incorrect color, and alignment flips. Fix failures before handoff.\n\n## Step 7: Hand off\n\nVerify through the production exporter first when you can. Probe for\n`emaillove_export_figma` and `emaillove_preview_email` before delegating verification to the\nuser: when connected, run the desktop preview export on the root, run the mobile preview,\nfix anything either render disproves, and include the preview link in the report. End every\nbuild with exactly one completion state:\n\n- `desktop and mobile export verified`: both production renders exist and pass; desktop\n  success never substitutes for untested mobile output.\n- `built in Figma, export verification pending`: canvas and structure checks passed but no\n  production render has been seen.\n- `blocked`: plus the exact action needed to continue.\n\nReserve `export-ready`, `fixed`, and `verified` for the evidence those words imply; a named\ninbox-client test is a separate claim from a production Preview pass.\n\nReport:\n\n- what was built;\n- Path A, Path B, or mixed, and why;\n- components selected or converter structure used;\n- repairs applied;\n- inspiration used;\n- assumptions;\n- provisional links and mobile keys;\n- dark-mode overrides preserved or added;\n- placeholder imagery or unresolved facts;\n- anything skipped.\n\nPropose a subject under 45 characters and a complementary preheader. Remind the user to set\nor verify them in the Email Love plugin, review mobile and dark-mode previews, export through\nthe plugin, and send a real inbox test.\n\nNever use an em dash in email copy, Figma layer names, or plugin-data values.\n"
}