What problem does it solve?
Frontend work in the Mastra ecosystem often drifts off the design system: developers hand-write colors, font sizes, and shadows, guess token names from memory, or rebuild components that already exist. This Skill enforces the boundary between look (owned by the design system) and layout (owned by the consumer) so every screen stays consistent.
Core Features & Use Cases
- Component discovery rules: Directs you to browse
packages/playground-ui/src/ds/components/ and src/domains/ before building anything new, preventing duplicate components.
- Token and class selection hierarchy: Provides a five-rung decision ladder from DS variants down to square-bracket arbitrary values, with
theme.css as the single source of truth for token names.
- Theme contract and wiring guidance: Explains the dark/light palette flip via
html.light, the cn() utility with its extended twMerge config, and when local CSS custom properties beat new @theme tokens.
- Use Case: When adding a settings dialog to a Mastra app, use this Skill to compose existing
ds/ primitives, size the dialog with max-w-100, and avoid review smells like bg-[#hex] or dark: overrides on semantic tokens.
Quick Start
Use the mastra-frontend skill to build a new page in the playground UI using existing design system components and theme tokens.