AI-operability
This page gives an overview of the progress made toward making Quantum more AI-operable.
In this context, AI-operable means making the Design System easier for AI assistants, coding agents, and automated workflows to understand, navigate, and apply reliably.
AI-operability resources at a glance
The tables below summarize a concise set of high-level resources and assets that matter for AI-operability. They are inspired by the kinds of capabilities highlighted in the broader Design System landscape and can be used as a framework to assess Quantum’s current maturity and future priorities.
1. Distribution & discovery
| Element | Description | Status |
|---|---|---|
| MCP server | Exposes components, tokens, icons, patterns and docs as agent tools, either local (stdio) or remote (hosted). This is the most common affordance in mature AI-operable design systems. | Not started |
llms.txt | A root index of docs with one-line descriptions generated from the same source as the docs site. | Available |
llms-full.txt | A full concatenated dump generated from the same source as the docs site. | Not started |
Sliced llms-*.txt variants | Context-budget slices by concern (components, styling, theming, migration) so agents load only what the task needs. | Not started |
| Markdown twins of docs pages | Every docs page is available as .md (URL suffix, Accept: text/markdown negotiation, or a “Copy for LLM” button). | Available |
| Agent-optimized markdown | A denoised markdown layer curated specifically for LLM ingestion, with reduced chrome and explicit structure. | Not started |
| Per-section markdown bundles | Combined markdown exports for major areas such as components, tokens, foundations, migration or theming. | Not started |
| Agent discovery layer | .well-known/ manifests (skills index, api-catalog, MCP server card), Link headers and sitemap.md for automatic agent discovery. | Not started |
2. Agent instructions
| Element | Description | Status |
|---|---|---|
| Agent skills | An installable SKILL.md router with reference files loaded on demand, plus task-oriented skills for building, migrating and auditing. | Not started |
| Editor rules | .github/copilot-instructions.md, path-scoped .github/instructions/*.instructions.md and .cursor/rules/*.mdc, used to guide agents in consumer or contributor environments. | Not started |
AGENTS.md | Root and per-package instruction files for contributor agents, covering conventions, commands and the definition of done. | Not started |
DESIGN.md | A portable design-context manifest covering principles, tokens and key do/don’t rules. It should be treated as a complement, not as the primary agent interface. | In progress |
| AI documentation section | A dedicated documentation section covering setup, supported tools, sample prompts, workflows and usage guidance for AI-assisted work. | Available |
3. Tooling
| Element | Description | Status |
|---|---|---|
| DS CLI | A deterministic action surface for agents (setup, add, info --json, lint, migrate) that can also generate or install agent configuration in consumer repos. | Not started |
| Lint rules | Design-system-specific lint rules that help enforce token usage, ban deprecated APIs and catch unsupported overrides, ideally with autofix support. | Not started |
| Codemods | Automated migration scripts between Design System versions, with agent-friendly output and predictable execution. | Not started |
| Registry / examples corpus | Addressable, validated code snippets, patterns and templates that serve as canonical references for generation. | Not started |
| Agent hooks | Pre- and post-edit hooks such as format, lint and typecheck that run automatically in agent sessions. | Not started |
| Design tools bridges | Bridges to design tools such as Figma or Penpot, including assets like Code Connect, design-to-code mappings and token mappings. | In progress |
4. Quality
| Element | Description | Status |
|---|---|---|
| Validation loop | A required validation cycle for agent output, typically based on linting, typechecking, accessibility checks and conformance verification. | Not started |
| Compliance checker | A tool that evaluates an interface or a codebase against Design System rules and assets to assess its compliance with the system. | Not started |
| Guardrails | High-level constraints that prevent unsupported output, such as verify-before-use rules, deprecated API bans, token-only styling and approved design-source allowlists. | Not started |
| AI evaluation suite | Prompt-to-expected-output evaluations run in CI on changes to skills, rules, prompts or MCP assets, with pass-rate thresholds and published results. | Not started |
Why this matters
As AI tools become part of everyday design and development workflows, a Design System is no longer only consumed by humans.
It is also increasingly consumed by:
- coding assistants working inside IDEs
- agents that generate or modify UI code
- tools that inspect design tokens and component APIs
- workflows that connect design, documentation, and implementation
If Quantum is not structured for these use cases, AI-generated output becomes less reliable. It may use the wrong components, invent patterns that do not exist, or produce code that is inconsistent with the system.
Improving AI-operability helps reduce that gap. The goal is not to let AI replace design and engineering judgement, but to make Quantum easier to use correctly in AI-assisted workflows.