design-system-architecturelisted

# Design System Architecture ## Coverage Design and audit reusable UI systems. Covers token taxonomy, semantic vs raw tokens, component APIs, variants, slots, theming, accessibility contracts, responsive behavior, documentation, governance, migration, and drift detection between code and design intent. ## Philosophy A design system is a product architecture layer, not a style pile. Tokens and components should encode durable decisions so product work becomes faster and more consistent. If every screen still makes local choices for color, spacing, state, and behavior, the design system is only decorative. Optimize for clear constraints. A system with too many escape hatches is not flexible; it is ungoverned. ## Method 1. Inventory tokens, components, variants, and usage hotspots. 2. Separate raw tokens from semantic tokens. 3. Define component contracts: purpose, props/slots, states, accessibility, and composition rules. 4. Establish theming and density rules before multiplying variants. 5. Mark forbidden local overrides and migration paths. 6. Add docs examples that show expected use and anti-use. 7. Verify real screens can be built without one-off styling. ## Evals This skill ships a comprehension-eval artifact at [`examples/evals/design-system-architecture.json`](https://github.com/jacob-balslev/skill-graph/blob/main/examples/evals/design-system-architecture.json). The checklist below is the authoring gate for design-system architecture decisions; the eval file is