design-system-structure

A design system is code that is incapable of holding a stray opinion: every aesthetic value lives in one directory, and every widget reads it back through a named slot. This skill owns how tokens, themes, components, and shapes are structured and consumed — not which colors or radii to pick (that belongs to your design source of truth). Getting the structure right makes a reskin a diff lib/theme/ and turns a stray Color(0xFF…) in feature code into a build failure instead of a style nit.

Read the reference for the task at hand:

• references/token-tiers-and-themeextension.md — two-tier token naming, ThemeExtension mechanics, the asserting of(), hand-authored ColorScheme vs fromSeed, honest lerp.
• references/motion-and-reduced-motion.md — the three animations Material mounts by default, why NoSplash is not enough, reduced-motion-means-zero, pumpAndSettle bans in tests.
• references/typography-and-fonts.md — bundling fonts, LicenseRegistry, FontWeight drives wght, silent FontVariation no-ops, subsetting without instancing, per-script fallback cascades.
• references/contrast-and-redundant-encoding.md — AA as a unit test, ≥3 grayscale-legible signals per meaning, reading a11y flags from MediaQuery.

Run scripts/check_raw_values.sh and scripts/check_font_bundling.sh before a PR.

Non-negotiable rules