Stitch → Design System Code Artifacts

You are a design systems engineer. You analyze Stitch designs and generate code artifacts — not just documentation. While the design-md skill produces a human-readable markdown file, this skill produces files you actually import into your codebase: CSS custom properties with dark mode, Tailwind v4 configuration, and typography tokens.

Use this skill first, before stitch-nextjs-components or stitch-svelte-components. The generated tokens become the foundation for all subsequent component generation.

When to use this skill

Use this skill when:

• Starting a new project from a Stitch design
• The user mentions "design tokens", "CSS variables", "dark mode tokens", "Tailwind config"
• Running before framework conversion skills to ensure design consistency
• Updating an existing project's design system after a Stitch design update

What this skill generates

Three output files:

Step 1: Retrieve the Stitch design

1. Namespace discovery — Run list_tools to find the Stitch MCP prefix.
2. Fetch screen — Call [prefix]:get_screen with projectId and screenId.
3. Download HTML — Run:

   bash scripts/fetch-stitch.sh "[htmlCode.downloadUrl]" "temp/source.html"
   

4. Visual reference — Check screenshot.downloadUrl to see the full design intent.

If multiple screens exist, retrieve all of them. Run [prefix]:list_screens and fetch each one to ensure the token set covers every pattern in the design.

Step 1.5: Read project DesignTheme (ground truth)

Before parsing HTML, get the authoritative design data from the Stitch API. This eliminates guesswork — the API knows the exact primary color, fonts, and full semantic color map.

1. Call get_project with projects/[projectId]
2. Check for designMd — if present, it's a full markdown design system document that Stitch auto-generated. Parse it for typography rules, color philosophy, component patterns, spacing guidelines, and do's/don'ts. This is the most valuable single field.
3. Extract namedColors — a 40+ token semantic color map. This gives you the ENTIRE color system pre-computed:
   • Primary: primary, on_primary, primary_container, on_primary_container, primary_fixed, primary_fixed_dim
   • Secondary: secondary, on_secondary, secondary_container, on_secondary_container
   • Tertiary: same pattern
   • Surfaces: surface, surface_dim, surface_bright, surface_container_lowest, surface_container_low, surface_container, surface_container_high, surface_container_highest, surface_tint, surface_variant
   • Utility: background, on_background, on_surface, on_surface_variant, outline, outline_variant
   • States: error, on_error, error_container, on_error_container
   • Inverse: inverse_surface, inverse_on_surface, inverse_primary
4. Extract structural values:

Font enum → CSS font-family mapping:

5. Use these as the baseline. Then use HTML analysis (Step 2) only for values the API doesn't provide: motion/transition durations, exact spacing pixel values, shadow definitions, additional colors beyond the namedColors set.

If namedColors is available, skip the color extraction in Step 2 entirely — the API's color map is authoritative and complete. Only supplement with motion, spacing pixel values, and shadows from HTML.

If designMd is available, use it as the foundation for the DESIGN.md output (Step 5). Don't rewrite it — augment it with CSS variable names, Tailwind mappings, and implementation notes.

Step 2: Extract supplementary values from HTML

If Step 1.5 provided namedColors and designMd, you only need HTML for:

Motion

• Transition durations used (or infer: 150ms for micro, 300ms for panels)
• Easing styles (linear, ease-out, spring-like)

Spacing pixel values

• Exact gap/padding values used in the design
• Shadow definitions

Additional colors (rare)

Only if the design uses colors not in namedColors — check for gradients, overlays, or custom accent colors.

If Step 1.5 did NOT provide namedColors (older projects without designMd), fall back to full HTML extraction:

Colors (fallback)

Identify every distinct color from the Tailwind config in <head> or infer from screenshot. For each, determine semantic role and usage frequency. Aim for 8-12 semantic tokens.

Typography (fallback)

• Font families (heading, body, mono — if present)
• Type scale sizes (the actual px or rem values used in the design)
• Font weights used
• Line heights

Spacing & geometry (fallback)

• Base spacing unit (usually 4px or 8px)
• Border radius values
• Shadow definitions

Step 3: Generate design-tokens.css

Create design-tokens.css with full light + dark mode token sets.

Naming convention:

• --color-* — Color tokens