Stitch mcp create design system
Skill gabelul/stitch-kit/skills/stitch-mcp-create-design-system
Creates a reusable Stitch Design System from theme tokens — colors, fonts, roundness. Can be applied to future screens for visual consistency.From its SKILL.md
npx -y skills add gabelul/stitch-kit --skill stitch-mcp-create-design-systemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
6.4 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it
Stitch MCP — Create Design System
Creates a new Stitch Design System — a reusable theme configuration that can be applied to any screen. This bridges the gap between local CSS token extraction (via stitch-design-system) and Stitch-native design tokens that persist across generations.
Critical prerequisite
Only use this skill when the user explicitly mentions "Stitch".
When to use
- After extracting CSS tokens via
stitch-design-systemand wanting to persist them in Stitch - User wants consistent theming across multiple screens or projects
- The orchestrator's Step 7 offers to create a Stitch Design System from extracted tokens
- User explicitly asks to create a design system in Stitch
Call the MCP tool
{
"name": "create_design_system",
"arguments": {
"designSystem": {
"displayName": "SaaS Dashboard Theme",
"theme": {
"colorMode": "LIGHT",
"headlineFont": "DM_SANS",
"bodyFont": "DM_SANS",
"labelFont": "DM_SANS",
"roundness": "ROUND_EIGHT",
"customColor": "#6366F1",
"colorVariant": "TONAL_SPOT"
}
},
"projectId": "3780309359108792857"
}
}
Parameter reference
designSystem — required object
| Field | Type | Required | Description |
|---|---|---|---|
displayName | string | Yes | Human-readable name for the design system |
theme | DesignTheme | Yes | Visual configuration — see below |
designTokens and styleGuidelines are not accepted — the live API has no such fields on DesignSystemInput. Don't send them.
theme (DesignTheme) — the visual configuration
Required: colorMode, headlineFont, bodyFont, roundness, customColor.
| Field | Type | Values | Description |
|---|---|---|---|
colorMode | enum | LIGHT, DARK | Base appearance mode |
headlineFont | enum | See font list below | Typeface for headings and titles |
bodyFont | enum | See font list below | Typeface for body text and paragraphs |
labelFont | enum | See font list below | Optional. Typeface for labels, captions, and UI chrome |
roundness | enum | ROUND_FOUR, ROUND_EIGHT, ROUND_TWELVE, ROUND_FULL (ROUND_TWO also exists but is deprecated/unused) | Border radius scale |
customColor | string | Hex color | Primary brand color |
colorVariant | enum | MONOCHROME, NEUTRAL, TONAL_SPOT, VIBRANT, EXPRESSIVE, FIDELITY, CONTENT, RAINBOW, FRUIT_SALAD | Optional. Palette generation strategy from customColor |
designMd | string | — | Optional. Design system markdown document |
overridePrimaryColor / overrideSecondaryColor / overrideTertiaryColor / overrideNeutralColor | string | Hex color | Optional. Exact color overrides, take precedence over customColor |
spacing | object | Map of name → CSS value | Optional. e.g. {"sm": "8px"} |
typography | object | Map of level name → Typography token | Optional. Each token: fontFamily, fontSize, fontWeight, letterSpacing, lineHeight |
font (the deprecated singular font field), backgroundLight, backgroundDark, preset, and description are not accepted as input — they only ever appear in API responses (get_project, list_projects, etc.), never in what you send here.
Available fonts (68 options)
Sans-serif: INTER, DM_SANS, GEIST, SORA, MANROPE, RUBIK, MONTSERRAT, WORK_SANS, SPACE_GROTESK, PLUS_JAKARTA_SANS, PUBLIC_SANS, SOURCE_SANS_3, NUNITO_SANS, ARIMO, HANKEN_GROTESK, IBM_PLEX_SANS, SPLINE_SANS, LEXEND, EPILOGUE, BE_VIETNAM_PRO, GOOGLE_SANS, GOOGLE_SANS_FLEX, GOOGLE_SANS_TEXT, NOTO_SANS, OPEN_SANS, KARLA, LIBRE_FRANKLIN, FIRA_SANS, CHIVO, QUESTRIAL, OUTFIT, BRICOLAGE_GROTESQUE, COMFORTAA, QUICKSAND, RALEWAY, ROBOTO_FLEX, SYNE, OSWALD, ANYBODY, ATKINSON_HYPERLEGIBLE_NEXT
Serif: NOTO_SERIF, NEWSREADER, DOMINE, LIBRE_CASLON_TEXT, EB_GARAMOND, LITERATA, SOURCE_SERIF_4, IBM_PLEX_SERIF, MERRIWEATHER, PLAYFAIR_DISPLAY, BODONI_MODA, VOLLKORN
Mono / code: JETBRAINS_MONO, GOOGLE_SANS_CODE, GOOGLE_SANS_MONO, SPACE_MONO, COURIER_PRIME
Condensed / display: BEBAS_NEUE, ANTON, ARCHIVO_NARROW, BARLOW_CONDENSED, CLIMATE_CRISIS, POIRET_ONE, METROPHOBIC
Deprecated aliases (still valid, prefer the replacement): SOURCE_SERIF_FOUR → SOURCE_SERIF_4, SOURCE_SANS_THREE → SOURCE_SANS_3, METROPOLIS → no direct successor
projectId — optional, numeric only
✅ "3780309359108792857"
❌ "projects/3780309359108792857"
If provided, associates the design system with a specific project. If omitted, creates a global design system.
Mapping CSS tokens to DesignTheme
When creating from extracted design-tokens.css:
| CSS Variable | → DesignTheme field |
|---|---|
--color-primary | customColor |
--font-family (headings) | headlineFont (map to closest enum value) |
--font-family (body) | bodyFont (map to closest enum value) |
--radius or --border-radius | roundness (4px→FOUR, 8px→EIGHT, 12px→TWELVE, 16px+→FULL) |
There's no input field for exact background hex values — backgroundLight/backgroundDark are response-only. Light/dark backgrounds come from colorMode plus the palette Stitch derives from customColor and colorVariant; use overridePrimaryColor etc. if you need to pin a specific palette slot instead.
Output
Returns an Asset object with a name field — store this for future update_design_system and apply_design_system calls:
{
"name": "assets/15996705518239280238",
"displayName": "SaaS Dashboard Theme",
"designSystem": { ... }
}
After creating
- Store the
namevalue (e.g.,assets/15996705518239280238). It's used two different ways:update_design_system'sdesignSystem.name— pass it as-is, with theassets/prefixapply_design_system'sassetId— strip the prefix, pass the bare numeric idgenerate_screen_from_text'sdesignSystemparam — pass it as-is, with the prefix
- Offer: "Apply this design system to existing screens?" →
stitch-mcp-apply-design-system - The orchestrator stores this for automatic application in Step 5b
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most mcp tooling skills give in ~1.8k tokens
Counted across 780 of the 1,136 authors here whose files we hold, read 2026-09-06
- Use Zod for input validationin 34 of 780, across 21 files
- Use stdio for local clientsin 27 of 780, across 10 files
- Restart Claude Code after configurationin 26 of 780, across 23 files
- Verify MCP server connection before using toolsin 23 of 780, across 17 files
- Define input schemas for every toolin 20 of 780, across 11 files
- Use Streamable HTTP for remote clientsin 18 of 780, across 8 files
- Pin SDK version in package.jsonin 17 of 780, across 6 files
- Keep server logic independent of transportin 16 of 780, across 6 files
- Verify SDK methods against official documentationin 15 of 780, across 5 files
- Format evaluation results as an XML filein 15 of 780, across 12 files
- Test servers using the MCP Inspectorin 15 of 780, across 14 files
- Create ten complex and independent evaluation questionsin 14 of 780, across 11 files
Said here and by no other author read
- Use only when user mentions Stitch
- Map CSS tokens to DesignTheme fields
- Store the returned asset name for future calls
- Offer to apply the design system to existing screens
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.