메뉴
Generate a complete, accessible brand design system from a brief — primitive → semantic → component DTCG tokens (color, type, spacing, radius, shadow, motion), light + dark, plus a single theme.css — verified for WCAG. Use when the user wants a from-scratch brand/design foundation, a new palette + type system, or a themeable token kit for a product.
Design a UI component spec to the house quality bar — anatomy, variants, sizes, the 8 states, token mapping, and accessibility. Use when the user wants to design or document a component (button, input, tabs, toast, combobox, date picker, modal, etc.) at the spec level before or alongside code. For generating framework code, use design-code.
Audit a UI or design against WCAG 2.2 AA/AAA and ARIA patterns, returning criterion-referenced findings with severity and specific fixes. Use when the user wants an accessibility check, contrast verification, keyboard/screen-reader review, or wants to confirm a component meets POUR.
Generate production-ready, accessible, token-driven component code for ANY framework — React+Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components/Lit, React Native, Flutter, Jetpack Compose, vanilla CSS, or CSS-in-JS. Use when the user wants working UI code for a component or screen in a specific stack.
Turn a reference image, screenshot, or mockup into token-driven, accessible code — infer the design system from the reference (palette, type scale, spacing, radius, layout archetype), map it to the 3-tier tokens, rebuild it, then verify with the kit's gates. Use when the user provides a design/screenshot and wants matching UI code.
Apply a visual direction — an archetype (high-end agency, editorial minimal, brutalist, soft-SaaS, dark-tech) or one of 138 named design systems (apple, linear-app, stripe, vercel, notion, material, shadcn, spotify, tesla…) — by resolving it into the token system. Use when the user wants a specific look/vibe/brand feel, or asks to make a design feel premium/expensive/non-generic.
Set up or run design QA gates — token + hardcoded-value lint, automated a11y (axe), contrast, visual regression across variants/states/themes/RTL, and the manual a11y checklist. Use when the user wants CI quality gates, to prevent design regressions, or to QA a component/screen before shipping.
| name | brandkit |
| description | Generate a complete, accessible brand design system from a brief — primitive → semantic → component DTCG tokens (color, type, spacing, radius, shadow, motion), light + dark, plus a single theme.css — verified for WCAG. Use when the user wants a from-scratch brand/design foundation, a new palette + type system, or a themeable token kit for a product. |
Stand up the foundation (one token system everything renders from) before any screen. Get this right and every page stays consistent and themeable from one place.
taste/design-taste.md → Brief Inference). Pick an anchoring archetype from taste/aesthetic-systems.md.action.primary/-hover/destructive, text.{primary,secondary,on-action,link}, surface.{page,card,raised}, border.{default,strong}, feedback.{success,warning,error,info} — and the dark overrides (designed, not inverted).tokens/motion.json-style durations/easings.tokens/*.json (3-tier) + a single theme.css (the one shared source, [data-theme="dark"] overrides). Optionally feed the token-build pipeline (token-build skill) for other platforms.python3 scripts/validate_tokens.py — valid JSON, all aliases resolve.python3 scripts/validate_contrast.py — required text/action/border pairs pass WCAG AA in light AND dark; border.strong ≥ 3:1.python3 scripts/validate_theme_refs.py — every component var(--…) resolves to the theme.Output is a verified token foundation — the measurable part is provable (run
npm run verify). Brand "feel" still benefits from a human review againsttaste/design-taste.md.