Prior art: data, AI and governance¶
This page covers design systems as data: registries and documentation platforms, MCP servers and AI context files, rules and linters, and how design systems govern contributions and versions. For each item it gives what the work is and what the module takes from it. Conformance records and the MCP tools are planned, and v0's rules have a simpler shape; see the concept. For how this fits the wider prior art, see the overview.
Checked against sources on 2026-10-04. Items marked unverified rest on vendor claims we couldn't check independently.
How to read the verdicts: adopt means use it as it is; adapt means take the idea and change its shape; learn means study it without depending on it; avoid means a known pitfall.
Design systems as data¶
Figma Code Connect · adapt¶
Maps one design component to implementations in several frameworks (React, web components, SwiftUI, Jetpack Compose) with a property mapping. It records the binding only.
For the module: the model for a realization record, with conformance added:
conformance { status, checkedRules, evidence }.
shadcn/ui registry · adapt¶
A JSON schema for addressable registry items with a dependency graph. Namespaced
registries (@acme/item) can reference each other, and an MCP server browses them.
For the module: the namespace and reference syntax for layers and implementations. The registry distributes code and has no rules or conformance.
registry-item.json · MCP server
Storybook manifests and MCP addon · learn¶
Component and docs manifests generated by static analysis of stories, plus an MCP addon that lets agents write stories and run interaction tests against them. In preview, with manifests for the React frameworks plus Angular and Vue on Vite.
For the module: a working verification loop: the agent generates UI, then runs tests.
zeroheight, Supernova, Knapsack, Specify · learn · unverified¶
Documentation platforms with APIs or MCP servers. zeroheight's MCP tools retrieve documentation pages. Supernova says it exposes entities and their relationships. Specify is a DTCG-based token engine.
For the module: agents work better with per-entity retrieval than with whole pages. By its own description, Supernova's entity graph is the closest commercial match to the module's model.
zeroheight MCP · Supernova · Knapsack
AI context¶
Vendor design system MCP servers · learn¶
Primer, Carbon and Atlassian expose their design systems over MCP; Polaris does it
through Shopify's broader developer MCP server. Salesforce offered beta LWC tools in
its DX MCP server, superseded by LWC skills as of August 2026. Most offer list or
search, get, examples and guideline tools, and some add review or lint tools (Primer
lint_css, Atlassian ads_analyze_a11y). Carbon's preview offers only doc and code
search.
For the module: the contract can back a provider-independent version of that tool set.
Primer · Carbon · Polaris · Salesforce
Figma MCP server · learn¶
Tools such as get_code_connect_map, get_variable_defs and search_design_system,
and a create_design_system_rules prompt. The Variables REST API needs a Full seat in
an Enterprise organization.
For the module: shows what agents need from the design side. Don't depend on the paid Variables API.
Atlassian's DESIGN.md evaluation · learn · unverified¶
In Atlassian's own internal test (task and run counts not published), their MCP server used about half the tokens of a DESIGN.md that loads everything every time (about 3.75M against 7.21M) and needed fewer turns. Showing component internals made agents more likely to recreate components instead of reusing them.
For the module: the API should be retrievable per entity, and should steer agents toward reusing components.
DESIGN.md (Google Labs) · adapt¶
YAML front matter for tokens plus markdown rationale. A CLI lints, diffs and exports to Tailwind or DTCG. Alpha, April 2026.
For the module: an export snapshot of the API, not the source of truth.
AGENTS.md · adopt¶
Repository-level agent instructions, now under the Linux Foundation's Agentic AI Foundation alongside MCP.
For the module: only a pointer to the design system API or MCP server.
llms.txt and Cursor rules · avoid¶
Static AI context files. Studies of llms.txt found no measurable effect on AI citations; we found no evidence either way for coding agents.
For the module: not a primary channel. They can be generated from the API if someone wants them.
Rules and linting¶
Rule-ID linters · adopt¶
Atlassian's ensure-design-token-usage, stylelint-polaris (40+ rules grouped by
category and used to measure coverage; archived with Polaris React), the SLDS Linter
with bulk autofix, and Mozilla's use-design-tokens.
For the module: every rule gets a stable id and an enforcedBy list of linter
rules. Coverage by category becomes the conformance measure.
Atlassian · stylelint-polaris (archived) · SLDS Linter
axe-core · adopt¶
Each accessibility rule has an id, classification tags (WCAG criteria and others), an impact level and a help URL. Results are reported as structured evidence.
For the module: the same metadata and evidence shape for design system rules.
Figma Check designs · learn¶
Design-side linting for hard-coded values, contrast, library mismatches and detached instances, with one-click fixes (Organization and Enterprise plans).
For the module: design-side checks should report against the same rule IDs as code-side linters.
RFC 2119 and RFC 8174 · adopt¶
MUST, SHOULD and MAY as defined requirement levels; RFC 8174 clarifies that they carry that meaning only in capitals.
For the module: the grading scale for rules.
Governance¶
GOV.UK lifecycle and contribution criteria · adopt¶
Two published component statuses (Trial, Stable), and five contribution criteria: Useful and Unique to propose a component, then Usable, Consistent and Versatile to publish it.
For the module: the statuses as an enum, extended with deprecated and retired following Nathan Curtis, and the criteria to govern the shared vocabulary.
Nathan Curtis: versioning and tiers · adopt¶
SemVer for design systems, and a core tier with subsystem tiers per business line, under a centrally curated namespace.
For the module: tiers map to the module's layers. Each entity gets a SemVer and a deprecation lifecycle.