create-design-system

name	create-design-system
description	Skill to use if user asks you to create a design system or UI kit
user-invocable	true

Create design system

Design system creation instructions: Design systems are folders on the file system containing typography guidelines, colors, assets, brand style and tone guides, css styles, and React recreations of UIs, decks, etc. They give design agents the ability to create designs against a company's existing products, and create assets using that company's brand. Design systems should contain real visual assets (logos, brand illustrations, etc), low-level visual foundations (e.g. typography specifics; color system, shadow, border, spacing systems), reusable UI components, and high-level UI kits (full screens).

No need to invoke the create_design_system skill; this is it.

An automated compiler reads this project, bundles the components into a runtime library, and indexes the styles. It discovers everything from file content and sibling relationships — not from folder names — so the only fixed location is:

• styles.css at the project root (or index.css / globals.css / global.css / main.css / theme.css / tokens.css — first match wins). This is the global-CSS entry point; consumers link this one file. Keep it as a list of @import lines only. Everything it transitively @imports is shipped to consumers; @font-face rules anywhere in that closure declare the webfonts.

Organize everything else however suits the brand. A sensible default layout (use it unless the attached codebase or brand has its own convention):

• tokens/ — CSS custom properties, one file per concern (colors.css, typography.css, spacing.css, …), each @imported from styles.css.
• components/<group>/ — reusable React UI primitives.
• ui_kits/<product>/ — full-screen click-through recreations of real product views.
• guidelines/ — foundation specimen cards and deeper-dive prose.
• assets/ — logos, icons, illustrations, imagery.
• readme.md (root) — the design guide and manifest.

What the compiler looks for, regardless of path:

• A component is any <Name>.jsx / <Name>.tsx (PascalCase stem) with a sibling <Name>.d.ts in the same directory. Add <Name>.prompt.md alongside, and one @dsCard-tagged .html per directory (its first line is <!-- @dsCard group="…" -->; details under "Components" below).
• A token is any --* custom property declared under :root (or a single-selector theme scope) in a file reachable from styles.css.
• A font is any @font-face rule in that same closure; its src: url(…) targets are the binaries shipped to consumers.

To begin, create a todo list with the tasks below, then follow it:

• Explore provided assets and materials to gain a high-level understanding of the company/product context, the different products represented, etc. Read each asset (codebase, figma, file etc) and see what they do. Find some product copy; examine core screens; find any design system definitions.
• Create a readme.md (root) with the high-level understanding of the company/product context, the different products represented, etc. Mention the sources you were given: full Figma links, GitHub repos, codebase paths, etc. Do not assume the reader has access, but store in case they do.
• Call set_project_title with a short name derived from the brand/product (e.g. "Acme Design System"). This replaces the generic placeholder so the project is findable.
• IF any slide decks attached, use your repl tool to look at them, extract key assets + text, write to disk.
• Explore the codebase and/or figma design contexts and write the token CSS files — CSS custom properties on :root, both base values (--fg-1, --font-serif-display) and semantic aliases (--text-body, --surface-card). Copy any webfonts/ttfs into the project and write the @font-face rules in a CSS file. Then write the root styles.css as a list of @import lines only (never inline rules there) that reaches every token and font-face file.
• Explore, then update readme.md with a CONTENT FUNDAMENTALS section: how is copy written? What is tone, casing, etc? I vs you, etc? are emoji used? What is the vibe? Include specific examples
• Explore, update readme.md with VISUAL FOUNDATIONS section that talks about the visual motifs and foundations of the brand. Colors, type, spacing, backgrounds (images? full-bleed? hand-drawn illustrations? repeating patterns/textures? gradients?), animation (easing? fades? bounces? no anims?), hover states (opacity, darker colors, lighter colors?), press states (color? shrink?), borders, inner/outer shadow systems, protection gradients vs capsules, layout rules (fixed elements), use of transparency and blur (when?), color vibe of imagery (warm? cool? b&w? grain?), corner radii, what do cards look like (shadow, rounding, border), etc. whatever else you can think of. answer ALL these questions.
• If you are missing font files, find the nearest match on Google Fonts. Flag this substitution to the user and ask for updated font files.
• As you work, create foundation specimen cards (small HTML files) that populate the Design System tab. Target ~700×150px each (400px max) — err toward MORE small cards, not fewer dense ones. Split at the sub-concept level: separate cards for primary vs neutral vs semantic colors; display vs body vs mono type; spacing tokens vs a spacing-in-use example. A typical foundations set is 12–20+ cards. Skip titles and framing — the card name renders OUTSIDE the card, so just show the swatches/specimens/tokens directly with minimal decoration. Each card links (relative path from wherever you put it) so it picks up the real tokens. Tag each card with as its first line — the Design System tab renders every tagged in the project, grouped verbatim by . Suggested groups: "Type", "Colors", "Spacing", "Brand" — title-cased, consistent.

Components

• These are the brand's reusable UI primitives. When a concrete source defines the inventory (a mounted .fig file, a Figma link, a component library in an attached codebase), that inventory IS the component list — build exactly the families the source defines, nothing more. Do not add primitives a design system "usually" has (Toast, Avatar, Tabs, …) when the source doesn't define them; a component with no counterpart in the source is an invention consumers will trust and designers won't recognize. If an addition is genuinely needed (e.g. an Icon wrapper for a glyph set), list it in readme.md under "Intentional additions" with a one-line reason. Only when NO source defines components (brand-guidelines-only or from-scratch runs) should you author a standard set — Button, IconButton, Input, Select, Checkbox, Radio, Switch, Card, Badge, Tag, Tabs, Dialog, Toast, Tooltip — sized to the brand's needs. Either way, group by concern (e.g. forms/, feedback/, navigation/ under whatever parent directory you choose); a single core/ group is fine for a small set.
• Enumerate before you build: list the source's FULL component inventory FIRST (for a mounted .fig, read /METADATA.md's "Component families" section; for a Figma link, list the file's pages and components via get_design_context), put every family on your todo list, and build ALL of them, tracking progress against that list. Do NOT stop at a "core subset". If you cannot finish, end your turn by reporting exactly which families remain unbuilt and ask the user whether to continue — never end silently incomplete.
• Each component is one file <Name>.jsx (or .tsx) with export function <Name>(props) {…} — a named, PascalCase export; that name becomes the public API and the literal export keyword is required so the bundler picks it up. Keep them self-contained: import React only, reference styling via the CSS custom properties (no CSS-in-JS libs, no npm packages). Siblings may import each other with relative paths.
• In the same directory, write <Name>.d.ts with the props interface — the sibling .d.ts is what gives a component its props contract, adherence rules, and starting-point eligibility; a .jsx without one is still bundled and exported under the namespace but gets none of those — and <Name>.prompt.md (first line is a one-sentence "what & when", then a small JSX usage example, then notable variants/props).
• One card HTML per directory (name it whatever you like — e.g. buttons.card.html): first line is <!-- @dsCard group="Components" viewport="700x<height>" name="<Directory label>" -->. Link styles.css via the correct relative path, load the bundle via (relative path to project root), then mount with in a block — call to get the exact . Do NOT the directly (its is unreachable from inline script). Show key states/variants (primary/secondary/ghost; sizes; disabled; with icon; etc.). Make it dense and scannable, not a single default render.

Starting points

• Consuming projects show a "Starting Points" picker that lets users seed a new design with a component or screen from this system. Entries are opt-in via a tag — separate from @dsCard (which populates the Design System tab).
• To mark a component: add @startingPoint section="<group>" subtitle="<one line>" viewport="<WxH>" to the JSDoc on its <Name>.d.ts props interface. The picker thumbnail is that directory's @dsCard-tagged HTML, so make sure it renders sensibly at the declared viewport.
• To mark a screen: add <!-- @startingPoint section="<group>" subtitle="<one line>" viewport="<WxH>" --> as the first line of the HTML file. The screen itself is the thumbnail.
• When the user says "create a starting point <X>" (or "add <X> as a starting point"), write an HTML file with the <!-- @startingPoint section="…" --> comment as its first line — any .html in the project with that tag is indexed. ui_kits/<x>/index.html is the conventional home but not required.
• When the user asks to remove or retitle a starting point, edit the tag. When they ask to change a thumbnail, edit the @dsCard-tagged HTML in that component's directory (component) or the screen HTML itself.

UI kit details:

• UI kits are high-fidelity visual + interaction recreations of full interfaces — screens, not primitives. They cut corners on functionality (not 'real production code') but are pixel-perfect, created by reading the original UI code if possible, or using figma's get-design-context. UI kits compose the component primitives you authored above; don't re-implement Button inside a kit. A UI kit's index.html must look like a typical view of the product. These are recreations, not storybooks.
• To start, update the todo list to contain these steps for each product: (1) Explore codebase + components in Figma (design context) and code, (2) Create 3-5 core screens for each product (e.g. homepage or app) with interactive click-thru components, (3) Iterate visually on the designs 1-2x, cross-referencing with design context.
• Figure out the core products from this company/codebase. There may be one, or a few. (e.g. mobile app, marketing website, docs website).
• Each UI kit contains JSX (well-factored; small, neat) for that product's surfaces — sidebars, composers, file panels, hero units, headers, footers, blog posts, video players, settings screens, login, etc.
• The index.html file should demonstrate an interactive version of the UI (e.g a chat app would show you a login screen, let you create a chat, send a message, etc, as fake)
• You should get the visuals exactly right, using design context or codebase import. Don't copy component implementations exactly; make simple mainly-cosmetic versions. It's important to copy.
• Cover every component family the source defines — coverage means the full enumerated inventory, not a hand-picked subset. Within a UI kit screen you may abbreviate repeated content (e.g. 3 rows standing in for 30 identical ones), but never skip a component family.
• Do not invent new designs for UI kits. The job of the UI kit is to replicate the existing design, not create a new one. Copy the design, don't reinvent it. If you do not see it in the project, omit, or leave purposely blank with a disclaimer.

Guidance

• Run independently without stopping unless there's a crucial blocker (E.g. lack of Figma access to a pasted link; lack of codebase access).
• When creating slides and UI kits, avoid cutting corners on iconography; instead, copy icon assets in! Do not create halfway representations of iconography using hand-rolled SVG, emoji, etc.
• CRITICAL: Do not recreate UIs from screenshots alone unless you have no other choice! Use the codebase, or Figma's get-design-context, as a source of truth. Screenshots are much lossier than code; use screenshots as a high-level guide but always find components in the codebase if you can!
• The attached kit is the ground truth. When its values differ from the published conventions of a component library it resembles (shadcn, MUI, etc.), the kit wins. Copy exact numeric values — paddings, radii, font sizes, line-heights — from the source; never round or snap them to a 4/8-px grid or a framework default. If the kit says 5px, write 5px, not 4px.
• Avoid these visual motifs unless you are sure you see them in the codebase or Figma: bluish-purple gradients, emoji cards, cards with rounded corners and colored left-border only
• Avoid reading SVGs -- this is a waste of context! If you know their usage, just copy them and then reference them.
• When using Figma, use get-design-context to understand the design system and components being used. Screenshots are ONLY useful for high-level guidance. Make sure to expand variables and child components to get their content, too. (get_variable_defs)
• Stop if key resources are unnecessible: iff a codebase was attached or mentioned, but you are unable to access it via local_ls, etc, you MUST stop and ask the user to re-attach it using the Import menu. These get reattached often; do not complete a design system if you get a disconnect! Similarly, if a Figma url is inaccessible, stop and ask the user to rectify. NEVER go ahead spending tons of time making a design system if you cannot access all the resources the user gave you. This applies mid-run too: if reads start failing or rate-limiting partway through, stop and report exactly what you did and did not read — never infer or invent component names, structures, or values for content you could not read.

SKILL.md

• When you are done, we should make this file cross-compatible with Agent SKills in case the user wants to download it and use it in Claude Code.
• Create a SKILL.md file like this:

<skill-md>
---
name: {brand}-design
description: Use this skill to generate well-branded interfaces and assets for {brand}, either for production or throwaway prototypes/mocks/etc. Contains essential design guidelines, colors, type, fonts, assets, and UI kit components for protoyping.
user-invocable: true
---

Read the README.md file within this skill, and explore the other available files.
If creating visual artifacts (slides, mocks, throwaway prototypes, etc), copy assets out and create static HTML files for the user to view. If working on production code, you can copy assets and read the rules here to become an expert in designing with this brand.
If the user invokes this skill without any other guidance, ask them what they want to build or design, ask some questions, and act as an expert designer who outputs HTML artifacts _or_ production code, depending on the need.
</skill-md>

Additionally, remind the user they need to set the File type to Design System in the Share menu so that others in their org can view this design system.