LLM Wiki

Appearance

Built 26/04/17 09:39commit 8de3d61

Agent-Readable Design Systems ​

中文 | English

Summary ​

An agent-readable design system keeps frontend taste and UI constraints in versioned markdown so models can generate, revise, and review interfaces against explicit visual rules instead of guessing from vague adjectives.

Core Pattern ​

  • DESIGN.md plays the same role for look-and-feel that AGENTS.md plays for implementation behavior: both are durable control surfaces for autonomous work.
  • The best design-control documents encode concrete, reusable rules rather than mood-board language alone.
  • Markdown is useful because it is already the native reading format for coding agents and does not require parsing-side infrastructure.

What The Contract Should Capture ​

  • Theme and atmosphere: what the interface should feel like, how sparse or dense it should be, and which design philosophy it should avoid.
  • Semantic palette roles: named colors, functional usage, contrast expectations, and where accents are allowed.
  • Typography and spacing systems: font stacks, hierarchy, rhythm, whitespace, and grid logic.
  • Component-level rules: buttons, cards, inputs, navigation, surfaces, motion, and responsive behavior.
  • Prompt handoff guidance: a compact way to tell the agent which visual constraints are mandatory and which examples are just inspiration.

Why It Matters For Agent Work ​

  • Frontend quality is more reproducible when design intent is repo-local instead of hidden in a human designer's taste or in prior chat turns.
  • A library of named style references lets users choose by example, which is often easier than writing an abstract design brief from scratch.
  • Even lightweight local brand stubs are operationally useful if they preserve the named precedent and its short visual fingerprint, because an agent can still switch between concrete styles such as Claude, Vercel, Linear, Notion, Stripe, or Figma without leaving the repository.
  • Durable design contracts reduce repeated prompt overhead in the same way durable repo docs reduce repeated implementation guidance.
  • Text-driven visual artifacts extend the same pattern beyond UI styling: when architecture diagrams are generated from versioned markdown-like descriptions, visual system understanding becomes another agent-readable control surface instead of an external slide artifact.

Tradeoffs ​

  • A design-control document can drift from the actual product unless someone maintains it as the UI evolves.
  • Pattern catalogs are weaker than full local source captures when most brand-specific detail lives behind external URLs.
  • Design tokens and prose constraints help with visual matching, but they do not fully replace browser-based review, screenshots, and human judgment on interaction quality.

Sources ​