PLAYBOOK 01
Component architecture for the MCP era
A component is no longer a thing you draw and hand over. It is a contract three parties read — the user, the developer, and the machine. This playbook is how to write that contract so all three get the same answer.
20260422 · v1.0 · Hamish Duncan
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.
CLAUDE MCP
ACT, TASK OR SPEC prompts
FIGMA
Visual of the design system
VS CODE / CURSOR / GITHUB
Codebase edits and deployment
NOTION
Documentation, change log and version control
Webflow
Articles, portfolio, live playground and marketing
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)