Mastra Frontend
How to build Mastra frontend interfaces with the @mastra/playground-ui design system.
Install
npx skills add mastra-ai/mastra --skill mastra-frontend -g -a claude-code -y- Repository
- mastra-ai/mastra29.3k
- Category
- Design
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 1,709 tokens
- Runs scripts
- No, instructions only
What it does
How to build Mastra frontend interfaces with the @mastra/playground-ui design system. This skill should be used when creating or modifying any application UI, pages, components, styling, or tokens, in this repo or in an external consumer of the design system. The docs site has its own styling and is out of scope.
Building Frontend Interfaces
Every Mastra application UI is assembled from the @mastra/playground-ui design system. Building a screen is composition work: pick existing components, arrange them with layout utilities, and let the design system provide the look. Writing colors, font sizes, shadows, or radii by hand means you have left the happy path. Changing the design system itself (tokens, ds/ components, variants) is a separate, explicitly-approved task. For Tailwind v4 mechanics (renames, dynamic utilities, CSS-first APIs), read the tailwind-v4 skill.
The boundary: look vs layout
- Look, colors, typography, radius, shadows, borders, internal padding, belongs to the design system. Consumers never restyle it.
- Layout, positioning, flex/grid placement,
gap-*, margins, size constraints (w-*,max-w-*,min-h-*,shrink-0), belongs to the consumer, through Tailwind utilities on your own wrappers and, when needed, directly on DS components.
className on a DS component is fine for layout (<DialogContent size="xl" className="h-[80vh]">, where size picks the width and the class only pins the height) and forbidden for look (<Button className="bg-red-500 text-xs">). If a component's look doesn't fit, use its variants and props; if none fit, escalate for a new variant instead of overriding.
