Update to Email Love

{
  "description": "Diagnose and repair an existing Email Love email template or reusable module in Figma when the plugin rejects it, the canvas and export disagree, content flattens into images, Outlook clips text, mobile stacking or spacing is wrong, links or images fail, dark mode breaks, or component properties stop working. Use for targeted repair of Email Love structures that already exist. Do not use to create a new campaign, convert an ordinary Figma comp, or migrate a legacy library; route those to email-love-figma-builder or email-love-design-system-migration.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 488
    },
    {
      "relative_path": "references/diagnostic-workflow.md",
      "size_in_bytes": 5084
    },
    {
      "relative_path": "references/repair-verification.md",
      "size_in_bytes": 4310
    },
    {
      "relative_path": "references/symptom-cause-matrix.md",
      "size_in_bytes": 6302
    }
  ],
  "name": "email-love-template-repair",
  "skill_md_contents": "---\nname: email-love-template-repair\ndescription: Diagnose and repair an existing Email Love email template or reusable module in Figma when the plugin rejects it, the canvas and export disagree, content flattens into images, Outlook clips text, mobile stacking or spacing is wrong, links or images fail, dark mode breaks, or component properties stop working. Use for targeted repair of Email Love structures that already exist. Do not use to create a new campaign, convert an ordinary Figma comp, or migrate a legacy library; route those to email-love-figma-builder or email-love-design-system-migration.\n---\n\n# Email Love Template Repair\n\nRepair the smallest proven defect in an existing Email Love template or module, preserve what\nalready works, and verify the result through the production exporter before calling it fixed.\n\n## Non-negotiable boundaries\n\n- Diagnose before writing. Reproduce the reported failure and identify the node, breakpoint,\n  and mechanism.\n- Establish source fidelity before writing. Treat a failure screenshot as symptom evidence unless\n  the user explicitly identifies it as the intended design. Name the visual authority and the\n  structural authority separately. Never derive intended geometry from the broken canvas when an\n  original comp, migration audit, supplied HTML, or approved source render exists.\n- Preserve the original. For a campaign template, repair a duplicate unless the user explicitly\n  authorizes editing the original. For a library module, ask whether to repair the source component\n  in place, which updates its instances, or create a replacement.\n- Never detach an instance, rewrite design-system foundations, rename pages or tokens, or clear\n  deliberate dark-mode overrides.\n- Never build unknown `mj-section`, `mj-column`, or leaf scaffolding from memory. Replace a broken\n  component with an intact library instance, or reconstruct converter-built structure strictly from\n  the packaged render contract.\n- Never treat a clean plugin-data read-back or a good canvas screenshot as proof of a good email.\n  Desktop and mobile exporter renders are the arbiter.\n- Never say `fixed` when exporter verification is deferred. Say exactly what remains unverified.\n\n## Route the request\n\nClassify the target by MEASURED evidence of Email Love provenance, not by intact markers alone.\nMissing or incorrect markers are themselves supported repair defects (see the symptom matrix),\nso a damaged template must not be bounced to Builder just because the damage reached its markers.\n\nIntact provenance, route to repair directly:\n\n- A whole email has a root with `nodeType = mainFrame` and Email Love wrappers below it.\n- A reusable module is a COMPONENT tagged `mj-wrapper` and carries no `mainFrame` marker.\n- An Email Love component instance surfaces its main component's plugin data.\n\nDamaged provenance, still repair: when the root marker is missing, wrong, or misplaced, look for\nsurviving evidence before rerouting: `mj-*` tags or Email Love plugin data anywhere in the\nsubtree, an ancestry of wrappers/sections/columns in the Email Love shape, the plugin's display\nnames, a sibling or main component that carries the data, or the user stating it exported before.\nAny of those makes it a broken Email Love template with a marker defect; repair the marker per\nthe symptom matrix.\n\nNo provenance at all, reroute: a frame with zero Email Love tags anywhere, no tagged ancestry,\nand no history of exporting is an ordinary comp, however email-shaped it looks. Use\n`email-love-figma-builder` for one ordinary Figma comp or new campaign, and\n`email-love-design-system-migration` for a legacy library.\n\nAmbiguous provenance: ask the user one focused question (did this ever export through the Email\nLove plugin?) or run a focused read-only inspection before any mutation. Do not assume every\nemail-shaped frame is an Email Love template, and do not mutate anything to settle the question.\n\n## Check the tools\n\nBefore promising a repair, confirm the Figma tool catalog includes `use_figma`, `get_metadata`, and\n`get_screenshot`. If `use_figma` is absent, perform read-only diagnosis and give the user an exact\nhandoff; do not promise a canvas fix.\n\nProbe for `emaillove_export_figma` and `emaillove_preview_email` before deferring export checks.\nThe Email Love MCP may be connected separately from this skill's install (a portal skills-only\ninstall carries no MCP configuration; the Git-backed plugin bundles one), so when the tools are\nabsent, distinguish an UNCONFIGURED server (add it with `codex mcp add emaillove --url\nhttps://mcp.emaillove.com/mcp`), a configured server needing AUTHORIZATION (`codex mcp login\nemaillove`, then start a new task), and a connected server whose tools are UNAVAILABLE. Do not\nsend an unconfigured installation straight to login. Missing, unauthorized, or unavailable\nproduction rendering makes the exporter state `deferred`, not `pass`.\n\n## Load the repair references\n\nRead these three repair references for every task:\n\n- [Diagnostic workflow](references/diagnostic-workflow.md)\n- [Symptom and cause matrix](references/symptom-cause-matrix.md)\n- [Repair verification and report](references/repair-verification.md)\n\nLoad the shared exporter ground truth before any structural repair:\n\n- [Shared Email Love rules](../email-love-figma-builder/references/shared-rules.md)\n- [Geometry and root shapes](../email-love-figma-builder/references/render-geometry.md)\n- [Container and leaf mappings](../email-love-figma-builder/references/render-nodes.md)\n- [Components and validation](../email-love-figma-builder/references/render-components-validation.md)\n\nWhen the target is composed from design-system instances, also read\n[Path A](../email-love-figma-builder/references/path-a.md). Do not open instance internals to\nrepair them. Replace the instance or fix the source component under the user's chosen scope.\n\n## Run the repair\n\n### 1. Capture the failure\n\nRecord the file, page, target node id, root shape, reported symptom, affected breakpoint or email\nclient, and whether the issue appears on the canvas, in plugin Preview, in exported HTML, or only\nafter ESP delivery. Save a before screenshot and exporter render when available.\n\nFor HTML supplied by the user or exported by the plugin, treat the HTML as authoritative for the\nstructure it contains. Inspect its desktop DOM and mobile media behavior separately. A screenshot\ndoes not overrule supplied HTML.\n\n### 2. Protect the working state\n\nFor a campaign, duplicate the whole email root and name the copy `Repair working copy - <name>`.\nKeep the original untouched. Record the new root id.\n\nFor a module or main component, stop before the first write and settle impact with the user:\nrepairing the source in place changes every instance; a replacement changes none until swapped.\nNever make that choice silently.\n\nRecord node ids, component-property counts, property bindings, and the last verified state. This is\nthe resumable record if the task is interrupted.\n\nComplete every pending read-only investigation that could change the target node, source authority,\nbreakpoint intent, or repair dimensions before the first write. Parallel discovery does not permit\nearly mutation: wait for those checks, or record why an unavailable check cannot change the repair.\nThen freeze a compact Repair Contract before writing:\n\n```text\nRepair Contract\n- target: <node id> (<email root | module | instance | leaf>)\n- class: property_patch | instance_replacement | section_reconstruction\n- evidence: <the observed facts this repair rests on>\n- allowed nodes: <exactly the ids this class may touch>\n- change: <node id>: <before> -> <after>   (one line per intended change)\n- preserved invariants: <the ones this class can affect - root shape, node census, content\n  counts, tags, property bindings, tokens, assets>\n- rollback: <how the working copy reverts>\n- required checks: structure read-back; exporter desktop; exporter mobile\n  (+ canvas mobile when a mobile source exists)\n```\n\nKeep the record proportional to the repair: a link fix or root-marker fix needs no geometry\nfields; geometry and proof-instance mapping belong in the contract only when they can affect the\nmutation. One contract covers one scoped repair, and a user request that already clearly\nauthorizes that exact repair is its authorization - do not ask again for what was asked for.\nNew contradictory evidence invalidates the contract and stops further mutation until it is\nre-frozen. `property_patch` is the default class; `instance_replacement` and\n`section_reconstruction` are the two escalation classes and each requires its own contract naming\nwhat it may rebuild.\n\n### 3. Form one measured hypothesis\n\nUse the symptom matrix to identify the narrowest plausible mechanism. Inspect the complete ancestor\nchain around the failing node, not only the visible leaf. State the evidence and expected render\nchange before writing.\n\nApply one repair at a time. Read every geometry write back. Re-read\n`componentPropertyReferences` and compare property counts after structural changes. Shared plugin\ndata cannot override an existing private plugin value; when private data wins, direct the user to\nthe exact Email Love plugin control instead of repeating a write that cannot land.\n\n### 4. Escalate instead of patching indefinitely\n\nIf a rendered result disproves a change, revert that change on the working copy and do not repeat\nthe same idea elsewhere. After two failed local patches on the same section, stop patching.\n\nEscalate by re-freezing the contract under the next class: `instance_replacement` swaps the broken\ncomponent for an intact library instance; `section_reconstruction` rebuilds only that section from\nthe user's own source plus the converter and packaged render rules. Both name exactly what they may\nrebuild and what they must preserve. Never flatten a section or rebuild it from memory to make the\nsymptom disappear.\n\n### 5. Verify all three states\n\nRun the verification reference. Report five states, each on its own evidence:\n\n- `canvas desktop`: the Figma screenshot matches the authoritative desktop intent;\n- `canvas mobile`: compared only when a mobile source exists - otherwise `deferred`, never\n  inferred from desktop;\n- `structure`: the root, tags, geometry, bindings, and content checks pass;\n- `exporter desktop` and `exporter mobile`: the production renders pass, each verified\n  independently. An untested viewport is `deferred`, not `pass`, and success at one viewport\n  cannot compensate for failure at the other.\n\nA repair is `fixed` only when every required state is `pass`.\n\nIf the issue was reported in a named inbox client or ESP, exporter Preview is necessary but may not\nbe sufficient. State when a real inbox or ESP test still belongs to the user.\n\n## Progress contract\n\nBefore the first write, tell the user which target and copy you will repair, the suspected class of\nfailure, and a rough range in minutes. Update only at these boundaries:\n\n1. Failure reproduced and baseline captured.\n2. Structural repair applied and read back.\n3. Desktop and mobile exporter verification completed or explicitly deferred.\n\nRevise the estimate when the evidence changes the repair scope.\n\n## Hand off\n\nReturn the repair report from the verification reference. Include the original and working-copy\nnode ids, the proven cause, every node changed, before and after evidence, the three verification\nstates, any private-data or inbox-test handoff, and whether the original remained untouched.\n"
}