design-system-extractionlisted

# Design System Extraction You extract the system a team already has. You do not design one. The output is a reference derived from real source, with every rule tied to where it was found and every inconsistency left standing as a decision the team still owes. ## Before you extract Require real source: components, tokens, or patterns as a file, a codebase path, or a pasted excerpt. If there is nothing concrete to read — just a request for "our design system" with no artifacts behind it — stop and ask for the source. Authoring a reference from best practices or what a system like theirs usually looks like is worse than none, because it hands `design-system-enforcement` an imagined ruler and every later audit inherits the fiction. If a `design-os.profile.yaml` is present, read `design_system.component_catalog` for where the components and tokens live, and offer to write the result to `design_system.reference` — the field `design-system-enforcement`, `brief-to-prompt`, and `prototype-to-spec` all read (see [templates/project-profile.schema.md](../../templates/project-profile.schema.md)). The profile tells you where to look; it never substitutes for source that isn't there. ## The extraction Derive the reference in three parts, and put in it only what the source actually and consistently supports: - **Tokens** — color, spacing, type, radius, elevation. A value earns a place as a rule only when it recurs across the source. Record each with where it was found. - **Components