mcpField
S
specsfy-specialist-react

specsfy-specialist-react

github.com/promovaweb開発87306 回インストール1 週間前に更新
リポジトリ

specsfy-specialist-react について

フレームワークに依存しない React のコンポーネント、フック、フォーム、状態を実装・レビューする開発者向けのスキルです。UI 状態の明示、状態の適切な管理、外部システムとの同期に限った Effect の使用、振る舞いに基づくテストを重視します。

主な機能

  1. 01React コンポーネントとフックの指針
  2. 02状態の所有者と UI 状態のモデル化
  3. 03Effect と再レンダーの調査
  4. 04コンポジションとアクセシビリティの実践
  5. 05振る舞いに基づくテストの指針

活用シーン

  1. 01React フォームやコンポーネントの設計
  2. 02再レンダーや Effect のループの調査
  3. 03コンポーネント状態の置き場所の判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/promovaweb/specsfy --skill specsfy-specialist-react

インストール後、Claude Code で/specsfy-specialist-reactを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlreferences/standards.md

詳細

React

使用する場合

  • 依頼が、React 純粋環境(CRA、Vite、RSC 非依存)におけるコンポーネント、フック、コンテキスト、フォーム、リスト、エフェクト、または状態に関する場合に使用します。
  • コンポーネントが過剰に再レンダリングされる理由、エフェクトがループする理由、または状態をどこに持たせるべきかの判断方法を調べる場合にも使用します。
  • Server Component と Client Component の判断、データキャッシュ、またはフレームワークのルーティングには使用せず、その場合は $specsfy-specialist-nextjs を使用します。
  • 既製のビジュアルコンポーネントライブラリの選定や適応には使用せず、その場合は $specsfy-specialist-react-ui-components と $specsfy-specialist-ui-design を使用します。
  • コンポーネントが公開 props を提供する場合や、判別可能なユニオンで状態をモデル化する場合は $specsfy-specialist-typescript と組み合わせ、キーボード操作とスクリーンリーダーについて詳しく監査する場合は $specsfy-specialist-web-accessibility と組み合わせます。

フロー

  1. 画面またはフォームの場合、コードを書く前に INTERFACE.md と仕様のインターフェースのセクションを読みます。画面、情報の流れ、フィールド、バリデーション、表示パターン、状態を確認します。資料がない場合は $specsfy-specialist-ux-design と $specsfy-specialist-ui-design に戻します。依頼されたインターフェースをエンドポイントや空のコンポーネントに置き換えてはいけません。
  2. React のバージョン、レンダラー、フレームワーク(該当する場合)、プロジェクトの規約、すでに採用されているテスト戦略を確認します。画面で shadcn/ui を使用する場合は、$specsfy-specialist-shadcn-ui に従って、インストールされているプリミティブのベースを先に特定します。コンポーネントの見た目から Radix や Base UI と決めつけてはいけません。 .specsfy/STACK.md に React の記載がない場合、またはプロジェクトに React の依存関係がない場合は、この実装を開始せず、確認されたスタックの専門家に引き継ぎます。
  3. 画面に表示される状態(通常、読み込み中、空、エラー、古いデータ、楽観的更新)、それらを発生させるイベント、各データの所有者をモデル化します。
  4. 責務と小さな props を持つコンポーネントツリーを設計します。多数の真偽値フラグを持つ単一のコンポーネントより、コンポジション(children、スロット)を優先します。
  5. 各状態は、それを解決できる最も近い所有者に持たせます。useEffect で同期するのではなく、レンダー中に値を導出します。
  6. エフェクトは外部システム(DOM、サブスクリプション、ネットワーク、ストレージ)との同期にのみ使用します。すでに利用可能な props と state から値を計算するために使ってはいけません。
  7. 視覚的な仕上げの前に HTML のセマンティクスとキーボード操作を実装し、その後、観察可能な動作をテストで網羅します。
  8. 実際の症状がある場合にのみ、パフォーマンスを測定します(プロファイラー、本番環境のメトリクス)。そのうえで、測定結果を記録しながらメモ化するかコンポーネントを分割し、予防目的では行いません。
  9. 作成、変更、または再利用した各ブロックについて、責務、ファイル、props、イベント、状態、アクセシビリティ、利用する画面を INTERFACE.md に記録します。

パターン

  • 設定用 props が多い汎用コンポーネントより、合成を優先します。内部の判断分岐が増えてきたら、分割します。
  • React を使う Laravel では、プリミティブに shadcn/ui を、無料の合成コンポーネントに ReUI を使用します。ページとルートは React ブロックを合成し、グリッド、フォーム、フィルター、オーバーレイ、再利用可能なカードは独自コンポーネントとして実装し、INTERFACE.md に記載します。
  • 「初期値を保持する」ためだけに prop を state にコピーしてはいけません。これは同期ずれを引き起こすため、prop を直接読み取るか、レンダー中に導出します。
  • 既存の props/state から導出できる値の計算に useEffect を使ってはいけません。通常の変数を使うか、計算コストが高い場合は useMemo を使います。
  • loading、empty、error、stale、success を UI の明示的な状態として扱い、単一の boolean loading による暗黙的な分岐にしないでください。
  • リストではデータ由来の安定した key(id)を使います。順序が変わる場合や、項目が削除または並べ替えられる場合に、配列のインデックスを使ってはいけません。
  • 各 Context.Provider は、変更頻度と責務に応じて分離します。キー入力のたびに変わる context で、ツリー全体を囲んではいけません。
  • 事前に計測せずにメモ化(memo/useMemo/useCallback)を使ってはいけません。メモ化には比較コストがかかるため、高コストなレンダーや、頻繁なレンダーが実証されている場合にのみ効果があります。
  • 内部 hook の実装詳細ではなく、ユーザーが確認できる動作(テキスト、ロール、状態)をテストします。

アンチパターン

  • ローカル state を prop と同期するエフェクト(useEffect(() => setX(prop), [prop]))は、状態が重複している兆候です。真実のソースはすでに prop です。
  • state の変更を通じて別の effect を起動する effect の連鎖(「effect chain」)は、通常、単一のイベントハンドラーか、レンダー中の直接的な計算にまとめられます。
  • 依存配列が不完全な useEffect を // eslint-disable で「黙らせる」のは、古いクロージャのバグを解決するのではなく隠してしまいます。
  • アプリケーションのグローバル状態をすべて保持する単一の context(「god context」)は、変更のたびにツリー全体を再レンダーします。より小さな contexts を使うか、依存関係グラフが大きくなったら専用の状態管理ライブラリを使います。
  • このスコープを $specsfy-specialist-nextjs のスコープと混同しないでください。hook のエラーを「解決」するために "use client" を次々と追加するのではなく、適切な末端コンポーネントにインタラクティブな処理を移します。

検証

  • 変更した範囲全体をキーボードで操作し、新しいロール、フォーカス、または通知がある場合はスクリーンリーダーでテストします。
  • フローのステップ 2 でモデル化した各状態(nominal、loading、empty、error、stale、optimistic)と、エラーからの復旧についてテストを作成します。
  • React の警告(キー、順序が不正な hooks、アンマウント後の state 更新)と、SSR がある場合は hydration の警告がないか、コンソールを確認します。
  • 具体的なパフォーマンス上の仮説がある場合にのみ、プロファイリングまたはバンドル分析を実施し、実施前後の測定結果を添付します。
  • 上記の検証なしに、コンポーネントを「アクセシブル」または「高パフォーマンス」と称してはいけません。根拠のない断定的な表現は禁止です。

関連するスキル

  • $specsfy-specialist-reui は、無料カタログの React と Tailwind のコンポジションに使用します。
  • $specsfy-specialist-astro はアイランドの境界を管理し、$specsfy-specialist-shadcn-ui は primitives の基盤を特定してビジュアルコンポーネントを管理します。このスキルは、その内部の React の動作を管理します。
  • $specsfy-specialist-tailwind-css は、状態、effect、並行処理を管理することなくコンポーネントをスタイリングします。
  • $specsfy-specialist-nextjs は、サーバー/クライアントの境界、データキャッシュ、ルーティングに使用します。このスペシャリストは、フレームワークに依存しない React を扱います。
  • $specsfy-specialist-react-ui-components と $specsfy-specialist-ui-design は、既成のビジュアルライブラリの選定とコンポジションに使用します。このスペシャリストはその後、状態、エフェクト、テストの管理を担います。
  • $specsfy-specialist-typescript は、props、状態、判別可能な union を網羅的に型付けするために使用します。
  • $specsfy-specialist-web-accessibility は、ここで検証する基本的なキーボード操作を超える詳細な監査に使用します。

公式情報源を含む、状態モデリング、effects、コンポジション、リスト、context、テスト、パフォーマンスについては、references/standards.md をお読みください。

コメント