open-claude-design-systemlisted

# Design System Turn an existing visual language into authoritative tokens and reusable component contracts. Extraction is evidence work: the source may be inconsistent, but the result must not silently invent consistency. ## Important boundaries - Inspect the user's code, brand material, screenshots, or named reference before defining values. - Preserve source names and exact values when they are authoritative. Record near-duplicates and conflicts rather than merging them without a decision. - Match the project's existing token and component format. Do not introduce a second CSS/JSON/TypeScript/Tailwind representation by default. - A design-system request concerns product UI. Software architecture, distributed systems, schemas, and API design are outside this skill. ## Select the relevant procedure Read only the required references, resolved relative to this skill: | Request | Required reference | |---|---| | Colors, type, spacing, radii, shadows, motion, breakpoints, or theme tokens | `references/tokens.md` | | Reusable UI components, variants, states, composition, or a component inventory | `references/components.md` | Use both when the user wants a complete system or component library. Token extraction precedes component documentation because component contracts should name real tokens. ## Execution contract 1. Identify authoritative sources and their precedence, including bound design systems, UI kits, component sources, neighboring examples, and applicable temp