react:components

Overview of react:components skill

What react:components does

The react:components skill turns a Stitch design into modular React code for Vite-based frontends. It is built for agents that need to move from a screen capture or Stitch metadata to a maintainable component system, not just a one-off JSX dump.

Who it is for

Use this react:components skill if you are building or updating a frontend from Stitch and care about structure, token consistency, and validation. It is strongest for frontend engineers, design-to-code workflows, and agents that need a repeatable way to map a visual screen into components.

Why it is different

Compared with a generic prompt, react:components includes retrieval steps, local file checks, a design-fetch fallback, and AST-based validation. That matters when the main risk is not “can the model write JSX” but “will the output align with the design, existing files, and project constraints.”

How to Use react:components skill

Install and activate

Install the react:components skill with the directory’s standard skill command, then invoke it on a Stitch-backed design task. In practice, the react:components install step is the entry point, but the real value comes from providing a screen name, project context, and an output target such as “React component system” or “Vite component set.”

Give the skill the right input

Best prompts name the screen, the Stitch project, and the desired implementation shape. For example: “Convert the Landing Page screen in my Podcast Stitch project into modular React components for Vite, preserving layout and design tokens.” This is better react:components usage than “make this into React” because it gives the skill the page boundary, source system, and output expectations.

Read these files first

Start with SKILL.md for the workflow, then inspect resources/stitch-api-reference.md, resources/architecture-checklist.md, and resources/style-guide.json before generating code. Use examples/gold-standard-card.tsx to see the intended component style, and scripts/validate.js to understand what the skill will reject. If you need to fetch design assets manually, scripts/fetch-stitch.sh shows the supported download path.

Workflow that improves output

The skill expects a design retrieval step, then a local existence check for .stitch/designs/{page}.html and .stitch/designs/{page}.png, then code generation and validation. If local design files already exist, decide whether to reuse them or refresh from Stitch before regenerating. That choice affects whether the react:components guide follows cached design state or the latest MCP source.

react:components skill FAQ

Is react:components only for Stitch projects?

Yes, that is the best fit. The react:components skill is optimized for Stitch MCP input, not for arbitrary screenshots or freeform mockups. If you only have a loose product idea, a general React prompt may be enough; if you have Stitch metadata and want reliable mapping, this skill is a better fit.

Do I still need to write a detailed prompt?

Yes. The skill reduces setup work, but it still needs a clear screen name, project name, and desired component scope. Strong inputs help the react:components skill avoid guessing whether to produce a single component, a component tree, or a reusable module set.

Is this suitable for beginners?

It is usable for beginners, but it assumes you can recognize basic frontend concepts like props, layout, and design tokens. If you are new, the skill still helps because it bakes in the workflow, but you will get better results when you can describe the target UI and accept modular React output.

When should I not use it?

Do not use react:components if your task is mostly content writing, backend work, or a non-Stitch React feature. It is also a poor fit when you want a quick visual prototype without adherence to design metadata, validation, or token mapping.

How to Improve react:components skill

Provide design context, not just a name

The biggest quality jump comes from specifying which screen to convert, what should stay intact, and what can become reusable. For example, “Preserve spacing and typography from the desktop Stitch screen, but split repeated cards into reusable components” gives the react:components skill clearer structure than a vague conversion request.

State constraints that affect code shape

Mention framework boundaries, routing assumptions, asset handling, and any project conventions up front. If you need TypeScript, Tailwind, or Vite-compatible output, say so. If background images should become data rather than hardcoded CSS, include that constraint in the prompt so the skill can follow the same react:components install assumptions and validation path.

Watch for the common failure modes

The most common miss is asking for UI code without the source design details needed for accurate mapping. Another is requesting a single giant file when the skill is designed for modular output. A third is ignoring the validation rules, which can lead to hardcoded colors, missing interfaces, or template placeholders that fail the architecture checklist.

Iterate with a tighter second pass

If the first result is close but not production-ready, improve it by pointing to the exact issue: “split the header and card into separate components,” “replace static text with mock data,” or “align colors with style-guide.json.” That kind of react:components usage feedback is more effective than asking for “better code” because it targets the structure the skill already knows how to refine.