design-system-opslisted

# Design System Ops Building a design system is the easy part; keeping it alive is the work. Used systems **drift** — tokens go stale, components fall out of spec, teams fork patterns, and the gap between intent and implementation compounds silently. This skill is the **operations layer**: auditing, governing, documenting, and measuring a design system as a living product, the way a staff-level practitioner would — with explicit frameworks that produce findings and decisions, not generic advice. > Frameworks re-derived (stack-agnostic, not vendored) from the MIT-licensed > [`murphytrueman/design-system-ops`](https://github.com/murphytrueman/design-system-ops) > (© 2026 Murphy Trueman). The original is a 41-skill pack for Claude Code; this is a single > condensed skill carrying its highest-leverage operations frameworks. > **Sibling boundary.** This skill is the **over-time, system-wide operations** layer. It does NOT > build or style components (that is `component-design` and `radix-tailwind-component-patterns`), set > up the frontend app (`frontend-ui-engineering`, `frontend-repo-architecture`), check a screen > against the design system during implementation (`ui-ux-design`), or run a WCAG pass on one UI > (`accessibility-review`). Reach here when the question is about the **health, drift, governance, > token architecture, adoption, or maturity of the design system itself** — not about shipping one > feature. ## When to use - "How healthy is my design system?" / "audit