react:components

react:components スキルの概要

react:components ができること

react:components スキルは、Stitch のデザインを Vite ベースのフロントエンド向けにモジュール化された React コードへ変換します。スクリーンショットや Stitch のメタデータから、単なる一回きりの JSX 出力ではなく、保守しやすいコンポーネント体系へ落とし込む必要があるエージェント向けに作られています。

どんな人向けか

Stitch からフロントエンドを新規作成したり更新したりする際に、構造、トークンの一貫性、検証を重視するなら、この react:components スキルを使うとよいでしょう。フロントエンドエンジニア、デザインからコードへの変換ワークフロー、そしてビジュアル画面をコンポーネントに再マッピングする再現性の高い方法が必要なエージェントに特に向いています。

何が違うのか

汎用プロンプトと比べると、react:components には検索ステップ、ローカルファイル確認、デザイン取得のフォールバック、AST ベースの検証が含まれます。重要なのは「モデルが JSX を書けるか」ではなく、「出力がデザイン、既存ファイル、プロジェクト制約にきちんと整合するか」という点が主なリスクになる場面です。

react:components スキルの使い方

インストールして有効化する

ディレクトリ標準のスキルコマンドで react:components スキルをインストールし、Stitch ベースのデザインタスクで呼び出します。実際には react:components のインストール手順が入口ですが、本当の価値は、画面名、プロジェクトの文脈、そして「React component system」や「Vite component set」のような出力先を与えることにあります。

スキルに適切な入力を渡す

よいプロンプトには、画面名、Stitch プロジェクト名、望む実装の形を明記します。たとえば、「Podcast Stitch プロジェクトの Landing Page 画面を、レイアウトとデザイン トークンを維持したまま、Vite 向けのモジュール化された React コンポーネントに変換して」といった指定です。これは「これを React にして」よりも優れた react:components の使い方です。ページ境界、ソースシステム、出力要件がはっきりするからです。

先に読むべきファイル

まず SKILL.md でワークフローを確認し、そのうえでコード生成前に resources/stitch-api-reference.md、resources/architecture-checklist.md、resources/style-guide.json を確認してください。意図されたコンポーネントスタイルを把握するには examples/gold-standard-card.tsx が役立ちますし、スキルが何を拒否するかを理解するには scripts/validate.js を見ておくとよいでしょう。デザインアセットを手動で取得する必要がある場合は、scripts/fetch-stitch.sh に対応するダウンロード経路が示されています。

出力をよくするワークフロー

このスキルは、まずデザイン取得、その後 .stitch/designs/{page}.html と .stitch/designs/{page}.png のローカル存在確認、続いてコード生成と検証、という流れを前提にしています。ローカルにデザインファイルがすでにある場合は、そのまま再利用するか、再生成前に Stitch から更新するかを判断してください。その選択によって、react:components ガイドがキャッシュ済みのデザイン状態に従うのか、最新の MCP ソースに従うのかが変わります。

react:components スキル FAQ

react:components は Stitch プロジェクト専用ですか？

はい、それが最適な用途です。react:components スキルは、任意のスクリーンショットや自由形式のモックアップではなく、Stitch MCP 入力向けに最適化されています。ざっくりしたプロダクト案しかないなら、一般的な React プロンプトで十分な場合もありますが、Stitch メタデータがあり、正確なマッピングを求めるならこのスキルのほうが合っています。

詳細なプロンプトはそれでも必要ですか？

はい、必要です。スキルは準備作業を減らしてくれますが、画面名、プロジェクト名、そして求めるコンポーネント範囲は明確にしておく必要があります。入力が具体的であるほど、react:components スキルは、単一コンポーネントを出すのか、コンポーネントツリーを作るのか、再利用可能なモジュール群を作るのかを推測せずに済みます。

初心者にも向いていますか？

使うことはできますが、props、レイアウト、デザイン トークンといった基本的なフロントエンド概念を理解していることが前提です。初心者でも、ワークフローが組み込まれている点で役立ちますが、対象 UI を説明し、モジュール化された React 出力を受け入れられるほど、結果は良くなります。

どんなときは使わないほうがいいですか？

作業の中心がコンテンツ作成、バックエンド実装、あるいは Stitch と関係のない React 機能なら、react:components は使わないでください。デザイン メタデータ、検証、トークン マッピングに従わず、手早く見た目だけの試作品を作りたい場合にも、あまり向いていません。

react:components スキルを改善する方法

名前だけでなくデザインの文脈を渡す

品質を大きく上げるコツは、どの画面を変換するのか、何をそのまま維持するのか、何を再利用可能にしてよいのかを指定することです。たとえば、「デスクトップの Stitch 画面の余白とタイポグラフィは維持しつつ、繰り返し出てくるカードは再利用可能なコンポーネントに分割して」と伝えるほうが、曖昧な変換依頼よりも react:components スキルに明確な構造を渡せます。

コード形状に影響する制約を先に伝える

フレームワークの境界、ルーティングの前提、アセットの扱い、プロジェクト固有の規約は、先に伝えてください。TypeScript、Tailwind、Vite 互換の出力が必要なら、それも明記します。背景画像を CSS に直書きするのではなくデータ化したいなら、その制約もプロンプトに含めることで、スキルは同じ react:components のインストール前提と検証経路に沿って処理できます。

よくある失敗パターンに注意する

最も多い失敗は、正確なマッピングに必要なソースデザイン情報を渡さずに UI コードだけを求めることです。もう 1 つは、スキルがモジュール化出力を前提としているのに、巨大な単一ファイルを要求してしまうことです。さらに、検証ルールを無視すると、ハードコードされた色、欠けた interface、テンプレートのプレースホルダーなどが残り、アーキテクチャ チェックリストで落ちる原因になります。

2 回目のやり取りでは、より絞って指示する

初回結果がかなり近いが本番品質ではない場合は、問題箇所を具体的に指摘して改善してください。たとえば、「header と card を別コンポーネントに分ける」「静的テキストをモックデータに置き換える」「色を style-guide.json に合わせる」といった指示です。こうした react:components のフィードバックは、「もっと良いコードにして」と頼むよりも効果的です。なぜなら、スキルがすでに理解している構造の改善点を直接指定できるからです。