/figma-to-content

name: figma-to-content
description: "Use this to turn a Figma design into an AEM Edge Delivery Services (EDS / AEM / Franklin / Helix) content page in Document Authoring (DA, da.live). Triggers: \"build this Figma frame in EDS\", \"turn this Figma design into a DA page\", \"publish this design to da.live\", or providing a figma.com URL for a page. Reads the frame (and any annotations) via a Figma MCP, resolves each section to an existing block, a new isolated block, or default content (inferred against the project's existing blocks and confirmed with you, or read from annotations when the frame happens to have them), generates DA-compliant body-fragment HTML, and deploys via the DA Source API + preview."
license: Apache-2.0
metadata:
  version: "1.0.0"

figma-to-content — Figma design → EDS content page in DA

Read a Figma frame, assemble a page from EDS blocks and default content, and publish it to Document Authoring. Runs with a **Figma MCP** (to read the design) and a **DA IMS token** (to write content) — no proprietary tooling required.

This skill **orchestrates existing skills**; it does not reimplement DA rules, block knowledge, or block-building. **Invoke those skills — do not inline them.** The condensed rules quoted in this file are *pointers* to jog the right skill, never a substitute for loading it: when a phase names a skill, invoke it and work from its actual guidance. Running this file as a self-contained procedure — hand-writing blocks, authoring DA HTML from memory, skipping the browser/visual check — is the single most common way a run goes wrong. Phase 2.3 turns the confirmed plan into an explicit manifest of the sub-skills you must invoke.

Two paths

Classify each section of the design, then follow the matching path:

• **Content only** — every section maps to a block that **already exists** in

the target project, or to **default content** (plain headings/paragraphs/ images/buttons — no block). Author content and deploy. No code changes.

• **Content + code** — a section needs a block the project **does not have**,

or an existing block matches structurally but its **styling diverges** (the look lives in block-specific CSS you'd have to edit). Create it as a **new, isolated block** (via the block-building skills), push the code, then author content and deploy. **Never skin an existing block or add per-section rules to global CSS** — new, additive blocks only. (Retargeting the project's global design tokens is a separate, allowed theming step; see Guardrails.)

A single design usually mixes all three (known blocks + default content + one or two new blocks).

When to use

• The user has a Figma frame representing a page and wants it as an EDS page in DA.

The common case: a customer **already on EDS**, with their own blocks, gets a new design for a new page — some sections reuse existing blocks, some need new ones.

• **The default path is infer-and-confirm.** Usually the frame is **not**

annotated (e.g. the user just says "migrate this page"): the skill **infers** each section's mapping against the project's existing block palette and **confirms the plan** before building, asking whenever a section is ambiguous (Phase 2). This path needs nothing but the design itself.

• **Annotations are an optional accelerator — never required.** If a frame

happens to declare each section's block / default content / new block (see [references/annotation-contract.md](./references/annotation-contract.md)), those declarations are taken as authoritative and skip the inference for that section. Absent them, nothing is lost — the skill infers and confirms.

When NOT to use

• **Redesign / restyle an existing EDS site**, or convert arbitrary generated

static HTML (Mobirise, Relume, v0, exported Figma HTML). Use **snowflake**.

• **Universal Editor or AEM Cloud Service (Java/OSGi/JCR).** Out of scope.

Related skills — orchestrated by this one

| For | Use skill | |---|---| | DA IMS token (`DA_TOKEN`) | **da-auth** | | DA body-fragment HTML rules, Source API, preview/publish, media | **da-content** | | Whether a block exists + its authoring model & examples | **block-collection-and-party** | | Surveying the whole available block palette | **block-inventory** | | Designing a content model for a **new** block | **content-modeling** | | Building a **new** block (full dev workflow) | **content-driven-development** (invokes **building-blocks**, **testing-blocks**) | | Rendering a block + **visual comparison to the design** (the reuse gate) | **testing-blocks** (browser/Playwright screenshot + "compare implementation to design") |

The DA-write contract in Phase 5 is the same one **da-content** documents (see its `references/html-content.md` and `references/platform.md`).

---

Inputs (gather before Phase 1; ask if missing — never guess)

• **Figma reference** — file key + node id of the page frame (from the

figma.com URL or the current Figma MCP selection). A file usually holds **many frames** — desktop/mobile variants, A/B versions, work-in-progress copies of the same page. Confirm **exactly which frame** to build; don't assume the first or largest. Two frames that are variants of the *same* page are one page, not two — ask which is canonical rather than deploying both.

• **Target project** — a local checkout of the EDS project repo (needed to see

existing blocks under `blocks/`, and required for the content+code path to add block code). Its GitHub `{owner}`/`{repo}` and the deploy `{branch}`.

• **DA location** — `daOrg`, `daRepo` (the DA namespace), page `PATH` (no

extension, lowercase/dash only — see da-content platform rules). In the standard EDS+DA setup `daOrg`/`daRepo` **equal** the GitHub `{owner}`/`{repo}`; confirm, because Phase 5 writes to `daOrg`/`daRepo` but previews/renders on the GitHub `{owner}`/`{repo}`/`{branch}`.

• **`DA_TOKEN`** — via **da-auth**, which exports `$DA_TOKEN` and caches it at

`~/