mcpField
S
system-deconstruction

system-deconstruction

github.com/dragoon0xDesign & UI688 installsUpdated 35w ago
Repository

About system-deconstruction

system-deconstruction is a design skill for analyzing a design system layer by layer. It helps designers compare tokens, components, patterns, and layouts, including the gap between defined rules and the product in use.

Key features

  1. 01Assess token, component, pattern, and layout layers
  2. 02Check consistency within and across layers
  3. 03Identify spacing, type, and color quality signals
  4. 04Flag one-off components and inconsistent behavior

Use cases

  1. 01Auditing a product against its design system
  2. 02Finding spacing or semantic color inconsistencies
  3. 03Reviewing component states and composition

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dragoon0x/taste-skills --skill system-deconstruction

After installing, type/system-deconstructionin Claude Code to confirm it loaded.

Details

From the project README

System Deconstruction

Take a design system apart. Understand every decision.

How to use

  • /system-deconstruction Apply system analysis constraints to this conversation.

Constraints

System Layers
  • MUST identify and evaluate each layer independently:
    • Token layer: colors, spacing, radii, shadows, type scale
    • Component layer: buttons, inputs, cards, modals, navigation
    • Pattern layer: forms, tables, dashboards, settings, onboarding
    • Layout layer: grids, breakpoints, density modes
  • MUST check consistency within each layer and between layers
Quality Signals
  • Consistent spacing scale across all components
  • Type scale that follows a mathematical ratio
  • Color palette with clear, non-overlapping roles
  • Components that compose predictably
  • States that are systematically covered (not ad-hoc)
Quality Warnings
  • More than 3 one-off components that don't fit the system
  • Spacing values that almost match but don't (15px next to 16px)
  • Colors that serve different semantic roles in different contexts
  • Components that look similar but behave differently
Anti-Patterns
  • Evaluating a design system by its documentation instead of its actual usage
  • Ignoring the gap between what the system defines and what the product actually ships
  • Treating the system as sacred (systems should serve products, not the other way around)

Comments

Markdown supported