component-audit

Component audit

A skill for auditing a design system's component library across four dimensions: usage signals, complexity distribution, duplication, and coverage gaps. Produces an inventory with tiered findings and a prioritised action list.

Context

Component libraries accumulate silently. New components arrive through contributions. Old components persist because nobody wants to be the one who removes them. Variants proliferate because each edge case adds one more. The result is a library that grows in mass without growing proportionally in value.

A component audit brings the library back into focus: what is there, what is used, what duplicates what, and what is missing that teams have been building around. It is the maintenance work that makes the next year of development faster.

---

Configuration

Before producing output, check for a .ds-ops-config.yml file in the project root. If present, load:

• system.framework — pre-selects framework-specific inventory guidance
• system.component_count — pre-populates the small-system gate
• severity.* — overrides for finding severity ratings
• integrations.* — enables auto-pull for component data (see below)
• recurring.* — enables comparison with previous audit

Auto-pull integrations

If integrations are configured in .ds-ops-config.yml, pull data automatically:

Figma MCP (integrations.figma.enabled: true):

• Read the published library from integrations.figma.file_key via Figma MCP
• Extract the component inventory: names, variant counts, description status
• Use Figma library analytics (if available via REST API) to pull detach rates per component — high detach rates are a direct usage signal
• Cross-reference the Figma inventory against the code inventory to detect components that exist in design but not in code (or vice versa)

npm registry (integrations.npm.enabled: true):

• Pull download statistics for integrations.npm.package_name (or each package in integrations.npm.scoped_packages for monorepos) using npm view [package] --json or the npm registry API
• Use download trends (last 30 days, last 90 days) as a usage signal in Dimension 1
• For monorepos: note that per-package downloads are unreliable (see monorepo handling) — use as a directional signal only