System deconstruction
Skill Dragoon0x/taste-skills/skills/analysis/system-deconstruction
Agent skills for design taste and visual judgment. Hierarchy, typography, color, spacing, interaction quality, and the invisible decisions that separate good design from great design
npx -y skills add Dragoon0x/taste-skills --skill system-deconstructionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Break a design system into its constituent decisions and evaluate each one. Use when auditing design systems, evaluating consistency, or understanding how a product maintains quality at scale.
SKILL.md
1.6 KB, as published. Nobody here has run it
System Deconstruction
Take a design system apart. Understand every decision.
How to use
/system-deconstructionApply 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)