| name | Design System Architecture Review |
| description | Child skill under Build Quality UI/UX for design-system architecture: atomic-design taxonomy, token taxonomy and tiering, naming, governance, releases, intake, adoption, and product outcomes. |
| skill_type | procedure |
| altitude | domain |
| activation | progressive |
| parent_id | build_quality_ui_ux |
| depth | 1 |
| preserve_markdown | true |
| legacy_paths | ["product-and-design.design-system-architecture-review.skill","product-and-design/design-system-architecture-review","docs/research/youtube-library/skill-drafts/design-system-architecture-review/SKILL.md"] |
| reference_modules | [{"id":"design_system_architecture_review.token_taxonomy_and_ai_context","name":"Token Taxonomy, Tiering & AI-on-Grain Context","summary":"Three-tier token taxonomy (option/core, semantic, component/recipe) with naming and indirection rules; tokens as single source of truth published to code/Figma/docs/native; core + child/recipe systems; un-styled base + token themes; web components as cross-framework single source of truth; AI-on-grain rules (light component table-of-contents context, not fine-tuning; generate/translate/retrofit; Sentient Design). Cites Frost 2024 and Curtis.","when_to_load":["When the review goes deep on tokens — naming, tiering, scope, promotion, theming, or cross-platform/native publishing.","When reviewing or designing an AI feature that generates, scaffolds, translates, or retrofits UI from the design system."],"path":"references/token-taxonomy-and-ai-context.md"},{"id":"design_system_architecture_review.adoption_diagnosis","name":"Adoption Diagnosis — Distance, Virtuous Circle & Interface Inventory","summary":"Diagnoses low design-system adoption — root cause is distance between system and products; requires the virtuous circle (system→product AND product→system); names the two failure poles (pattern police, product capture); the interface-inventory audit + buy-in protocol; continuous-improvement/agency/native-controls/performance-is-design governance; and the 2015→2024 maturity diagnostic. Cites Frost 2015 and 2024.","when_to_load":["When the bottleneck is adoption (\"nobody uses the system\"), the system feels isolated, or the question is design-system ROI.","When you need the interface-inventory protocol, the virtuous-circle check, or the 2015→2024 maturity diagnostic."],"path":"references/adoption-diagnosis.md"}] |
| path | apps/web/src/lib/services/agentic-chat/tools/skills/definitions/design_system_architecture_review/SKILL.md |
Design System Architecture Review
Identity
Use this child when UI quality depends on the system behind the screen. Two things to settle before architecture detail: product outcome (what gets faster/safer/clearer) and adoption (is the system serving the products or policing them). A perfectly-built system nobody uses returns nothing.
This is a procedure skill at domain altitude — a child review pass under build_quality_ui_ux. Its own volatile detail (token mechanics, adoption protocols) lives in two reference modules it loads on demand, not in sibling skills.
Activation
- Reviewing or creating a design system, component library, token system, Figma/code parity model, documentation site, release process, or contribution workflow.
- The user asks about Atomic Design, design tokens, system governance, component naming, adoption, roadmaps, or design-system ROI.
- A screen-level review keeps finding repeated inconsistencies that need systemic correction.
Judgment
Atomic-design rules (fire every review — Frost 2015)
- Non-sequential. The five stages happen collectively. Don't treat it as buttons-first-and-pray. Reject any plan that sequences them as a waterfall.
- Template-vs-page is load-bearing. A system that never separates content scaffolding from real content ships brittle layouts. Flag it.
- Page = resiliency test. No page stage (no real-content stress test) → predicted brittleness; require it.
- Vocabulary is optional, the system isn't. If the team rejects atom/molecule/organism naming, that's fine — the methodology survives renaming. Do not litigate the words; litigate whether the structure exists.
- Lineage / DRY. Patterns nest (includes / web components); "change one pattern, every instance updates." Duplicate components that should be one pattern → consolidation finding with the lineage as evidence.
Adoption check (run on every review — Frost 2024)
The 2024 defining problem isn't "how to build a system," it's "nobody uses the system." Root cause: distance between the system and the products it serves (the team "went inward"). The fix is the virtuous circle: system informs products AND products inform the system.
Binary checks (load adoption-diagnosis if any fail or the user asks about adoption/ROI):
- Does the loop run both directions (build-with AND contribute-back)?
- Is the system in a failure pole — (compliance-enforcing the product) or (swept up in one product's whims)? Name neither, one, or which.
