design-system-architecture-review

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.