Stats
Actions
Tags
From design-system-ops
Assesses design system state via quick scan of size, tech stack, tokens, docs, and maturity, then recommends prioritized skills to run first.
How this skill is triggered — by the user, by Claude, or both
Slash command
/design-system-ops:triageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A skill for quickly assessing a design system's state and recommending which skills to run first, in what order, and why. Prevents the overwhelm of running all 38 skills when 3–5 would surface the critical findings.
A skill for quickly assessing a design system's state and recommending which skills to run first, in what order, and why. Prevents the overwhelm of running all 38 skills when 3–5 would surface the critical findings.
Design System Ops has 38 skills across 5 categories: audit, validate, document, govern, and communicate. Running all of them is comprehensive but overwhelming — especially for a team encountering the plugin for the first time. The triage skill reads the system's current state and produces a prioritised run plan: which skills to run first, which to skip for now, and which to return to later.
The triage skill is intentionally lightweight. It should take no more than 5 minutes of input-gathering and produce a run plan in under a minute. The value is in sequencing, not in depth — the subsequent skills provide the depth.
This skill produces a run plan — it does not run other skills itself. If the user wants a full automated sweep, point them to the /full-diagnostic agent instead. If the system has a single well-defined problem ("our tokens are a mess"), skip triage and go directly to the relevant skill. Triage is for when the team does not know where to start, not when they already know.
Gather the minimum information needed to assess the system's state. This is NOT a full audit — it is a triage scan.
Ask for or confirm:
If the user provides a codebase or repo path, do a quick scan:
Based on the scan, classify the system into one of four states:
Profile: Young system, small team, establishing foundations. Primary risk: Building without foundations (tokens, governance, documentation). Typical pain: "We're not sure if we're doing this right."
Profile: Mid-size system gaining adoption, starting to feel friction. Primary risk: Accumulating debt faster than paying it off. Typical pain: "Things are getting inconsistent" or "new teams are struggling to adopt."
Profile: Mature system with significant investment, maintaining at scale. Primary risk: Drift, governance gaps, documentation staleness. Typical pain: "We don't know the state of things" or "teams are going off-system."
Profile: System with accumulated problems, possibly declining adoption. Primary risk: System becomes irrelevant as teams work around it. Typical pain: "It's a mess" or "nobody uses it" or "we inherited this."
Based on the state classification, produce a prioritised skill run plan.
System: [name] State classification: [A/B/C/D] — [one-line description] Date: [date]
For each recommended skill:
| Priority | Skill | Why now | What it will tell you | Estimated time |
|---|---|---|---|---|
| 1 | [skill name] | [why this is the right first step for this state] | [what you'll learn] | [5–15 min] |
| 2 | ... | |||
| 3 | ... |
Limit the initial run to 3–5 skills. More than that dilutes focus.
| Skill | Why skip | When to revisit |
|---|---|---|
| [skill name] | [why it's not useful yet for this state] | [specific trigger for when it becomes relevant] |
| Skill | Prerequisite | When to run |
|---|---|---|
| [skill name] | [what needs to happen first] | [timing — e.g. "after token audit remediation is complete"] |
These are starting-point recommendations. Adjust based on the specific pain the team reported.
State A (New/small):
system-health — Establish a baseline score across all dimensionstoken-audit — Verify the foundation is solid before building on itcontribution-workflow — Establish governance early, before it becomes a problemState B (Growing):
system-health — Get the current picturecomponent-audit — Understand what you have, what's duplicated, what's missingnaming-audit — Catch convention drift before it compoundsadoption-report — Understand who's using it and who isn'tState C (Established):
drift-detection — The #1 risk for established systemstoken-compliance — Are tokens being used correctly at scale?adoption-report — Who's drifting and why?system-health — Overall picture for quarterly reviewState D (Legacy/struggling):
system-health — Honest assessment of where things standtoken-audit — Understand the structural foundation (or lack thereof)component-audit — Map the duplication and coverage gapsdrift-detection — Quantify how far consuming teams have divergedstakeholder-brief — Translate findings into a business case for investmentAfter running the recommended skills:
npx claudepluginhub murphytrueman/design-system-opsAssesses design system health across seven dimensions—tokens, components, documentation, adoption, governance, AI readiness, platform maturity—producing findings summary and prioritized actions.
Audits design systems for component coverage, token consistency, documentation quality, accessibility, and adoption health. Produces structured report with health scores and remediation roadmap.
Assesses design system maturity on 1-4 scale with metrics, evaluates adoption health and governance, analyzes component duplication, calculates custom vs system ratios, identifies barriers and debt trends.