Design System Interface for Persistent LLM Context

Feature request for product/service

Cursor IDE

Describe the request

The Problem

When building UI-heavy applications with Cursor, the LLM has no persistent, structured awareness of your design system. Every conversation requires re-explaining tokens, component patterns, spacing conventions, and brand guidelines , context that should just be there.

Today’s workarounds fall short:

Cursor rules (.cursorrules) help but are flat text , not structured or queryable
Figma MCP gives access to designs but not a distilled, consumable system
Storybook is great developer documentation but not optimized as LLM context
None of these are a single, managed source of truth the AI consumes natively
As a result, the AI generates inconsistent UI , wrong colors, mismatched spacing, incorrect font pairings, ad-hoc component patterns, unless you constantly remind it of your system. This is the #1 friction point in AI-assisted frontend development.

The Proposal

A dedicated Design System Interface within Cursor, a structured panel where teams define and manage design context that the LLM always has access to:

Tokens: colors: typography, spacing, border radii, shadows (synced from CSS variables, Tailwind config, or Figma variables)
Component Registry: not just names, but props, variants, usage guidelines, and do/don’t patterns
Layout Patterns : grid systems, breakpoints, container conventions
Brand Voice: tone, copy conventions, naming patterns
Live Sync : automatically pull from Figma, CSS custom properties, or design token files so context stays current as the system evolves

Think of it like how a database schema gives the LLM context about data structures: but for UI. A semantic layer that’s structured enough for the AI to reason about (“what’s the correct button variant here?”) but flexible enough to evolve with the product.

Why This Matters

I’m a UX Director at Hearst Magazines, and my team recently adopted Cursor on an enterprise account. I’ve been building a production React marketplace application entirely with Cursor, 200+ components, a full design token system (colors, typography, 8px spacing grid), BEM naming conventions, and a Storybook component library.

Even with detailed .cursorrules, I spend significant time correcting the AI on design system fundamentals it should already know. The knowledge is scattered across CSS files, component files, Storybook stories, and Figma, none of which the LLM consumes as structured, prioritized context.

A Design System Interface would:

Eliminate repetitive correction , the AI would know your system from the start
Improve consistency, generated UI would follow your tokens and patterns by default
Scale across teams, enterprise teams sharing a Cursor workspace would share design context
Bridge design and engineering, designers define the system, the AI respects it in code
Who Benefits

This isn’t just for solo developers. Enterprise teams, agencies, media companies, SaaS products, maintaining design systems across large codebases would see the biggest impact. It’s the missing piece between “AI that writes code” and “AI that writes code that looks like it belongs in your product.”

I’d love to see this on the roadmap and happy to provide more detail or collaborate on scoping it.

-Lenin Aviles UX Director, Hearst Magazines

Hey @Lenin_Aviles!

Thanks for the thoughtful feedback here!

To be honest, I’m not sure we’ve thought about Cursor as a place where the design system lives, rather than connecting with other tools (like Figma).

I’m curious if, beyond the Figma MCP server, you’ve used the other Skills from the Figma plugin? These would ideally help you get more consistent results. The Skills are quite comprehensive!