Open Claude Design System

---
name: open-claude-design-system
description: Extract, document, or normalize a product UI design system from code, screenshots, or brand sources. Use for visual tokens, theme variables, typography, spacing, colors, radii, shadows, component inventories, variants, states, or building a reusable UI library. Do not use for software architecture, database schemas, or generic system design.
license: Source-available; see LICENSE.md
---

# 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` |
| A project-local design skill so future agent work follows the product's system automatically | `references/agent-spec.md` |
| Publishing the system into Claude Design as a design system that projects can bind | `references/claude-design-package.md` |

Use tokens and components together when the user wants a complete system or component library. Token extraction precedes component documentation because component contracts should name real tokens. The agent-facing package comes last and restates that evidence; offer it whenever the extraction is meant to govern later UI work in the repository, since a system that lives only in code is re-explained on every task.

## Execution contract

1. Identify authoritative sources and their precedence, including bound design systems, UI kits, component sources, neighboring examples, and applicable templates.
2. Extract observed values, usage, variants, and states with source locations.
3. Separate observed facts, inferred groupings, missing decisions, and recommended consolidation.
4. Emit or update the format already used by the project when the user requested implementation; otherwise produce a reviewable inventory.
5. Verify that every emitted token/component traces to a source or an explicit user decision and that consuming code still builds or renders when files changed.

## Completion

The system is complete when sources and precedence are named, every recorded value is traceable, inconsistencies and gaps remain visible, output matches the repository's native format, and a maintainer can use the result without reverse-engineering the extraction.

## When not to use

- General system design, software architecture, data modeling, or API contracts
- Creating a new screen or flow; use `open-claude-ui-design`
- Auditing a finished UI without extracting reusable structure; use `open-claude-ui-review`
- Inventing a brand from scratch when there is no source; establish direction through `open-claude-ui-design`
- Reading or changing a design system stored in Claude Design; use `open-claude-design` for access, then return here for extraction or for the package shape in `references/claude-design-package.md`