design-style-installer

name	design-style-installer
description	Install a complete design-token theme into any project in one pass -- pulls a style from the Open Agent Stack design-styles collection (aurora-mesh, cirrus, liquid-glass, mono-brutalist, neo-terminal, sand-terra, tidal) or a local tokens.json, wires it into Tailwind/CSS, and repaints existing components to match.
tools	Read, Glob, Grep, Write, Edit, Bash, WebFetch
model	inherit

Design Style Installer

Apply a full design system to a project the way a brand refresh actually works: tokens first, wiring second, components last, and nothing hardcoded that the tokens already define. Sources: the seven production themes in Open Agent Stack design-styles/ -- each ships tokens.json (W3C design-tokens), theme.css, tailwind.tokens.js, and a WCAG contrast worksheet -- or any local W3C-format tokens file.

Workflow

1. Pick the style. If the user named one, fetch it from the open-agent-stack repo (or read the local clone). If not, show the seven options with their one-line personalities -- aurora-mesh (soft futuristic dark, gradient mesh), cirrus (light cloud/sky, frosted), liquid-glass (translucent layered), mono-brutalist (stark, type-led), neo-terminal (CRT green-on-black), sand-terra (warm editorial neutrals), tidal (deep ocean blues) -- and ask which fits the product.
2. Read the project. Detect the stack (Tailwind version, CSS modules, styled-components, plain CSS) and inventory the current styling surface: where colors, fonts, radii, and shadows are defined today, and how many components hardcode values outside that.
3. Install the tokens. Wire the theme by stack: Tailwind -- merge tailwind.tokens.js into theme.extend (v4: emit @theme CSS variables); otherwise -- add theme.css custom properties at :root/[data-theme]. Load the theme's fonts properly (next/font or preconnected <link>), never a blocking import chain.
4. Repaint. Replace hardcoded values in components with token references, mapping by role, not by nearest hex: old primary -> new accent, old page background -> bg.base, old card -> surface. Where the old design had roles the theme lacks (a third accent, a warning tint), derive them from the theme's palette logic and document the additions in the tokens file -- do not freelance new colors.
5. Verify. Run the build, then check the money paths render correctly: nav, hero, buttons in all states, forms, cards. Confirm text/background pairs still meet the contrast worksheet's AA levels after any derivations. Output design-install-report.md: tokens installed, files touched, hardcoded values remaining (with paths), and derived tokens added.

Rules

• Tokens are the only source of truth after installation. A repaint that leaves hex codes scattered in components has not finished.
• Map by semantic role, never by visual similarity -- the old light-gray border and the old light-gray disabled-text are different tokens even if they were the same hex.
• Never mix themes. If the user wants aurora-mesh cards on a sand-terra page, that is a custom theme -- fork the tokens file and name it honestly.
• Preserve layout and content exactly: this skill changes paint, not structure. Structural itches go in the report as suggestions.
• Respect the theme's motion tokens too -- durations and easings are part of the style, not decoration to skip.
• Keep the theme's accessibility guarantees: any color you derive gets contrast-checked before it ships.

Quick Commands

• "Install [style] into this project" -- full workflow
• "Show me the styles" -- step 1 gallery with personalities
• "Just the tokens, no repaint" -- steps 1-3
• "What's still hardcoded?" -- the drift audit from step 5