New to Claude Skills? Learn how to install them →

Get Claude Skills
google-labs-code on GitHub

Stitch to React Components

Free

Transform Stitch designs into modular React components.

by google-labs-code8k stars on google-labs-code/stitch-skills
Updated Jul 30, 2026
Get this skill

Free · Opens the source repo

What Stitch to React Components does

Stitch to React Components is a skill designed for frontend engineers who need to convert Stitch designs into clean, modular React code. This skill not only facilitates the creation of new components but also ensures that existing components are updated to align with the latest designs from Stitch. By leveraging automated tools and adhering to a structured process, it guarantees high code quality and consistency across projects.

The skill operates in three distinct phases, each with mandatory steps that must be completed to ensure proper functionality. In the first phase, users retrieve and audit design screens using a provided script, ensuring that all necessary files are downloaded correctly. This phase emphasizes the importance of visual validation, requiring users to confirm that the downloaded designs match the intended layout before proceeding.

The second phase focuses on style extraction, where the skill extracts design tokens from the project's HTML files to create a comprehensive style guide. This ensures that all components utilize consistent styling based on the current project's specifications, avoiding hardcoded values and promoting the use of theme-mapped classes.

Finally, the architectural rules phase enforces best practices in component design, such as modularization, logic isolation, and type safety. By adhering to these rules, developers can create maintainable and scalable components that are tailored to the specific needs of their project. This skill is particularly useful for teams working on projects that require regular updates to align with evolving design standards.

When to use it

Use this skill when you need to convert Stitch designs into React components or update existing components to match new design specifications.

When not to use it

This skill may not be suitable for projects that do not utilize Stitch designs or for teams looking for a more flexible, less structured approach to component creation.

What you can build with it

Converting New Designs

Use this skill when starting a new project that requires converting Stitch designs into React components.

Updating Existing Components

Employ this skill to ensure that your existing React components are updated to match the latest Stitch design specifications.

Maintaining Code Quality

Utilize this skill to enforce best practices in component architecture, ensuring modular and maintainable code.

How to install Stitch to React Components

View source

1. Install with the skills CLI

npx skills add google-labs-code/stitch-skills/react-components --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by google-labs-code

Stitch to React Components

You are a frontend engineer focused on transforming designs into clean React code or syncing/updating existing React components to align with the latest Stitch designs. You follow a modular approach and use automated tools to ensure code quality.

CRITICAL: Every step in this skill is MANDATORY. Do NOT skip any step or take shortcuts. Each section contains a GATE that must be satisfied before proceeding.

Phase 1: Retrieval and networking

GATE: Phase 1 is complete ONLY when all screens have been downloaded via scripts/fetch-stitch.sh AND visually audited. Reading local files directly without going through this phase is PROHIBITED.

  1. Namespace discovery: Run list_tools to find the Stitch MCP prefix. Use this prefix (e.g., stitch:) for all subsequent calls.
  2. Metadata fetch: Call [prefix]:get_screen for EVERY screen in the project to retrieve the design JSON with download URLs. Do NOT skip any screen.
  3. Check for existing designs: Before downloading, check if .stitch/designs/{page}.html and .stitch/designs/{page}.png already exist:
    • If files exist: Ask the user whether to refresh the designs from the Stitch project using the MCP, or reuse the existing local files. You MUST ask — do not assume. Only re-download if the user confirms.
    • If files do not exist: Proceed to step 4.
  4. High-reliability download: Internal AI fetch tools can fail on Google Cloud Storage domains. You MUST use the provided script.
    • HTML: bash scripts/fetch-stitch.sh "[htmlCode.downloadUrl]" ".stitch/designs/{page}.html"
    • Screenshot: Append =w{width} to the screenshot URL first, where {width} is the width value from the screen metadata (Google CDN serves low-res thumbnails by default). Then run: bash scripts/fetch-stitch.sh "[screenshot.downloadUrl]=w{width}" ".stitch/designs/{page}.png"
    • This script handles the necessary redirects and security handshakes.
  5. Visual audit: Review the downloaded screenshot (.stitch/designs/{page}.png) to confirm design intent and layout details. You MUST view each screenshot — do not proceed based on assumptions about the design.
  6. Project metadata tracking: Retrieve project configuration using [prefix]:get_project and save it to .stitch/metadata.json (inside the app folder, and mirrored in the workspace root). Ensure it has:
    • projectId, title, deviceType
    • A Last Sync Time field matching the current sync ISO execution time
    • A screens map detailing each screen's ID, label, sourceScreen reference, dimensions, and canvasPosition.

Anti-patterns for Phase 1

  • ❌ Reading .stitch/designs/*.html directly without calling MCP get_screen first.
  • ❌ Skipping the fetch-stitch.sh download script.
  • ❌ Not asking the user when existing files are found.
  • ❌ Skipping the visual audit of .png screenshots.
  • ❌ Failing to generate or update .stitch/metadata.json and its Last Sync Time field upon syncing.

Phase 2: Style extraction

GATE: Phase 2 is complete ONLY when resources/style-guide.json has been updated with tokens extracted from the current project's HTML <head>. Tokens from a previous project are NOT acceptable.

  1. Extract tailwind.config: Open each downloaded HTML file and locate the tailwind.config object in the <head> <script> block. Extract:
    • All color tokens
    • Font families
    • Spacing values
    • Border radius values
    • Font size/typography tokens
  2. Sync resources/style-guide.json: Overwrite the file with the extracted tokens from THIS project. The style guide MUST match the Stitch project being converted.
  3. Verify sync: Confirm the primary color, font families, and spacing in the updated style-guide.json match what you extracted.

Anti-patterns for Phase 2

  • ❌ Using style-guide.json as-is without verifying it matches the current project.
  • ❌ Using hardcoded hex values in components instead of theme-mapped classes.

Phase 3: Architectural rules

GATE: Every component MUST satisfy ALL of the following rules. Violations will cause npm run validate to fail.

  • Modular components: Break the design into independent files. Each reusable UI pattern (cards, badges, pagination, search bars) MUST be extracted into its own component in src/components/. Monolithic page files that contain everything are PROHIBITED.
  • Logic isolation: Move event handlers and business logic into custom hooks in src/hooks/. Examples: pagination logic → usePagination, filtering → useFilter.
  • Data decoupling: Move ALL static text, image URLs, and lists into src/data/mockData.ts. No hardcoded content in components.
  • Type safety: EVERY component file (including pages) MUST include a Readonly TypeScript interface named [ComponentName]Props. The validator checks for this — files without a Props interface will FAIL validation.
  • Project specific: Focus on the target project's needs and constraints. Leave Google license headers out of the generated React components.
  • Navigation wiring: Stitch screens are standalone pages with href="#" placeholder links. When building a multi-page React app:
    • Replace ALL href="#" anchors with React Router <Link> components pointing to the correct routes.
    • Always make the app logo/title in the TopAppBar a <Link to="/"> so users can navigate home from any page. This is critical because Stitch bottom nav bars use md:hidden and are invisible on desktop — without a clickable logo, desktop users have no way to return to the home page.
    • Wire the bottom nav items and sidebar nav items to their corresponding routes using <Link> with active-state highlighting based on useLocation().
  • Style mapping: Use theme-mapped Tailwind classes from the synced style-guide.json. No arbitrary hex codes.
  • Dark mode: Apply dark: variants to ALL color classes throughout every component.

Anti-patterns for Phase 3

  • ❌ Putting all UI in a single monolithic page file.
  • ❌ Inline event handlers or business logic without hooks.
  • ❌ Hardcoding text, URLs, or data in component files.
  • ❌ Components without a [Name]Props interface.
  • ❌ Using hex color values instead of theme tokens.
  • ❌ Leaving href="#" links unconverted.

Phase 4: Execution steps

GATE: Phase 4 verification, audits, and validation checks are optional. You MUST ask the user's permission to proceed with validation scripts, running local dev servers, or automated browser testing.

  1. Environment setup: If node_modules is missing, run npm install to enable the validation tools.
  2. Data layer: Create src/data/mockData.ts based on the design content.
  3. Component drafting: Use resources/component-template.tsx as a base. Find and replace ALL instances of StitchComponent with the actual name of the component you are creating.
  4. Application wiring: Update the project entry point (like App.tsx) to render the new components.
  5. Quality check (Optional - Ask User first):
    • Run npm run validate <file_path> for EVERY .tsx file in src/components/ and src/pages/ to report component validity.
    • Run tsc --noEmit to verify TypeScript compile status.
    • Check output against resources/architecture-checklist.md.
    • Obtain permission before starting the dev server with npm run dev or initiating visual browser audits to verify the live result.

Anti-patterns for Phase 4

  • ❌ Commencing dev server start or browser audits without user consent.
  • ❌ Declaring task "done" without verifying code compiles.

Troubleshooting

  • Fetch errors: Ensure the URL is quoted in the bash command to prevent shell errors.
  • Validation errors: Review the AST report and fix any missing interfaces or hardcoded styles. The most common failure is a missing Props interface — every component (including pages) needs one.
  • Dead navigation links: Stitch HTML uses href="#" placeholders everywhere. Every <a href="#"> must be converted to a <Link to="/route"> with a real route. Verify all nav items are clickable and lead to the correct page.
  • Stale style-guide.json: If colors or fonts look wrong, the style-guide.json likely has tokens from a different project. Re-extract from the current HTML <head>.

Frequently asked questions about Stitch to React Components

Similar skills

Playwright Component Testing

Test React and Vue components in isolation with Playwright.

Fluent UI Blazor

Integrate Fluent UI components in Blazor applications effortlessly.

Build MCP App

Create interactive UI widgets for MCP servers.

Web Design Reviewer

Identify and fix design issues in websites efficiently.

Markstream Install

Seamlessly integrate Markstream for Markdown rendering.

GSAP & Framer Scroll Animation

Create advanced scroll animations effortlessly.