Component Spec as Data
Approach where each design system component exposes a structured spec (JSON Schema, TypeScript types, or YAML manifest) that AI agents consume to understand props, variants, states, constraints. Concept formalized by Nathan Curtis (EightShapes) and presented at Smashing Amsterdam 2026: the spec is no longer a Figma page or human-only MDX, it becomes machine-readable data co-existing with source code. Agents read the spec before generating or reviewing a component usage. The recommended concrete format in 2026 is the Component Manifest (Storybook MCP, March 2026), compact JSON/YAML (2-5KB per component) exposing props/variants/states/a11y to the LLM via MCP.
Strengths
- Single source of truth consumable by humans (auto-generated docs) AND AI agents
- Automatic validation: a usage violating the spec fails in CI before merge
- Foundation for DS MCP servers, custom lints, automatic test generation
Limitations
- Double maintenance: TS code + JSON spec must stay in sync (unless auto-generated)
- Tooling still fragmented in 2026, no universal standard (mix of JSON Schema, TS, YAML)
Best for
- Design system manager wanting to expose DS to multiple AI agents without rewriting docs each time
- Team shipping an MCP server for their DS (Storybook MCP or custom)