system-deconstruction
Skill5 starsChanged 8 months agoMITView on GitHub
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.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
MUST identify and evaluate each layer independently:
- Distinctive: line 22
MUST check consistency within each layer and between layers
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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)
In this repository38 other files it gives its agents.
- absence-auditSkill
- decision-tracingSkill
- version-archaeologySkill
- audience-translationSkill
- critique-vocabularySkill
- design-rationaleSkill
- written-critiqueSkill
- field-notesSkill
- learning-by-makingSkill
- quality-checklistSkill
- self-assessmentSkill
- flow-patternsSkill
- motion-designSkill
- timing-feedbackSkill
- constraint-evaluationSkill
- design-rankingSkill
- taste-as-strategySkill
- taste-gapSkill
- taste-vs-trendsSkill
- tradeoff-assessmentSkill
- consumption-disciplineSkill
- cross-domain-seeingSkill
- detail-observationSkill
- screenshot-surgerySkill
- visual-auditSkill
- cross-pollinationSkill
- library-architectureSkill
- principle-taggingSkill
- daily-routinesSkill
- design-critiqueSkill
- teaching-tasteSkill
- type-as-signalSkill
- type-selectionSkill
- type-systemsSkill
- color-systemsSkill
- craft-signalsSkill
- hierarchy-principlesSkill
- spatial-rhythmSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.