Thesis

When a human developer reads a design file and the system is incomplete, they fill the gaps with judgement. The product ships. The gap closes silently and no one logs it.

When an AI agent reads the same file through an MCP server, the gap is loud. Unresolved colours come back as `#000000`. Missing variants default. Class names get invented. The silence is now noise.

The fix is not better aesthetics. It is a component architecture written so the spec answers every question before the question is asked.

Every component has three architectures

Most teams build one. A coherent system specifies all three.

Pillar 01 — Visual

What the user sees

The aesthetic surface. Colour, type, spacing, motion. The part the client notices and the part most reviews focus on. Necessary, but on its own it tells you nothing about how the component should behave at the next size, in the next state, or under the next theme. The visual layer is the symptom of the system, not the system itself.

Pillar 02 — Semantic

What the role is

The naming and intent layer. What this thing is called, what it is for, which token it resolves to, what variant it belongs to. CEL lives here. A card__title--featured is not a styling decision — it is a role declaration. The semantic layer is what lets a designer in Figma, a developer in code, and an AI agent through MCP all reach for the same component when the brief says featured card.

Pillar 03 — Machine

What the agent consumes

The data attributes, the documentation, the schema. data-cel-context, data-cel-layer, the prop definitions, the constraints. The part that has no visual surface and that humans rarely read. Without it, AI generation is guesswork. With it, AI generation becomes resolution.

How the architectures move between tools

Same component. Same spec. Three operators — designer, developer, agent — all reading from the same source.

FIGMA

Visual of the design system

VS CODE / CURSOR / GITHUB

Codebase edits and deployment

CEL is the contract layer

CEL^* — Context · Element · Layer — is the naming methodology that turns a class name into a contract. It scopes the component, names the part by role rather than tag, and declares the variant as a layer. Three parts maximum. Lowercase. No nesting.

card

context only

card__title

context + element

card__title--featured

context + element + layer

card--dark

context + layer (no element)

*
CEL is a separate methodology with its own page.

Read the CEL Methodology

From spec to instance, in four steps

The mechanical part. Each step is a discrete handover, and each one fails loudly if the spec is silent.

STEP 01 - Connect

Connect Figma and Webflow to their MCP servers. The Designer tab stays foregrounded — close it and the connection drops. Test with a simple call before doing anything structural.

Step 02 — Resolve

The agent reads the brief and resolves it against the system. Featured card with dark theme should map to card cc-featured u-mode-dark without clarification. If it does not, the spec has a gap — fix the spec, not the prompt.

Step 03 — Instantiate

The agent creates the element. Batches of two or three at a time — larger batches time out. The element inherits the component's classes, attributes, and structure as defined by the spec.

Step 04 — Verify

Inspect the result in the Designer. Check the class stack, the data attributes, and the visual against the Figma source. Anything missing is a spec problem, not a generation problem.

Known limits, current as of v1.0

Six or more element creations may time out

Use batches of two or three. The connection holds; the request payload is the bottleneck. If a section needs ten elements, plan four sequential calls, not one.

The Designer tab must stay foregrounded

Switch to another tab and the WebSocket connection drops without warning. Keep the Designer visible during any agent run. Use a second screen if you need to read documentation simultaneously.

Elements cannot be moved

Restructuring requires creating a new element in the correct position and deleting the old one. Plan structure before instantiation; reordering after is twice the work.

Binary asset upload is unsupported

Images, fonts, and other binary assets cannot be uploaded through the MCP. Upload manually via the Designer asset panel, then reference the asset by its existing ID in subsequent calls.