フロントエンド開発スキル

フロントエンド開発スキル は何をしますか？

シニアレベルの、実践的でプロダクション対応のフロントエンドエンジニアリング。目標は常に、動作し、保守可能で、パフォーマンスの高いコードです。学術的な純粋さを追求するものではありません。

スタック検出

まず最初に、コンテキストからスタックを特定します。不明な場合は質問します。その後、適切なリファレンスファイルを読み込みます。

スタック	読み込むファイル
React (GraphQLなし)	references/react.md
React + GraphQL/Relay	references/react-graphql.md
Angular	references/angular.md
TypeScript (全スタック)	references/typescript.md (スタックファイルと併せて読み込む)

プロジェクトが明示的にJSのみでない限り、スタックファイルに加えて常に references/typescript.md を読み込みます。

---

普遍的な原則

これらの原則はスタックに関係なく適用されます。スキップしないでください。

アーキテクチャ

• 関心を積極的に分離する：UIレンダリング、ビジネスロジック、データ取得、副作用は異なるレイヤーに配置します。コンポーネントにfetch呼び出し、生のAPI文字列、ビジネスルールを含めてはいけません。
• タイプ別ではなく機能別に配置する：トップレベルの components/、hooks/、tests/ フォルダよりも、features/user-profile/ のようにコンポーネント、フック、テスト、スタイルをまとめて配置することを推奨します。アプリの複雑さに応じて構造をスケーリングし、小規模なアプリで過剰にエンジニアリングしないでください。
• 継承よりも合成を優先する：小さく焦点を絞ったコンポーネントを合成してUIを構築します。深いコンポーネント階層は避けてください。
• 時期尚早な抽象化はしない：同じものを二度書いてから抽象化します。一つのユースケースに基づいた抽象化はたいてい間違っています。

コンポーネント設計

• コンポーネントは一つのことだけを行うべきです。変更理由が複数あるコンポーネントは分割します。
• プレゼンテーションコンポーネント（純粋なUI、副作用なし）とコンテナ/スマートコンポーネント（データ、ロジック、オーケストレーション）を分離します。
• Propsインターフェースは明示的に型付けする必要があります。any、object、{} を型として使用しないでください。
• フォームにはデフォルトで管理コンポーネントを使用します。

パフォーマンス（譲れないベースライン）

Core Web Vitalsの目標値（実ユーザーの75パーセンタイルで測定）：

• LCP ≤ 2.5秒（読み込み）
• INP ≤ 200ms（インタラクティブ性 — 2024年3月にFIDから置き換え）
• CLS ≤ 0.1（視覚的安定性）

普遍的なパフォーマンスルール：

• 長い同期タスクでメインスレッドをブロックしない
• ルートと重いコンポーネントはデフォルトで遅延読み込みする
• すべての画像とメディアに明示的な寸法を設定する（CLSを防止）
• LCP画像には fetchpriority="high" を使用する
• 重要でないサードパーティスクリプトは遅延実行する
• レイアウトスラッシングを避ける（DOMの読み取り/書き込みをバッチ処理する）
• bfcacheの適合性を有効にする：unload リスナーを避け、不必要な no-store を避ける

デザインシステム & トークン

• デザイントークン（色、スペーシング、タイポグラフィ、角丸、シャドウ）を基本情報として定義し、コンポーネントに値をハードコードしない
• CSSカスタムプロパティ（--color-primary）またはトークンシステム（Style Dictionary、Tailwind設定）を使用してテーマを一元管理する
• アトミックデザインをメンタルモデルとして：atoms → molecules → organisms → templates → pages。命名を強制する必要はありませんが、この階層で考える
• コンポーネントをStorybookに文書化して、分離、発見可能性、視覚的リグレッションテストを実現する
• アクセシビリティは必須：WCAG 2.1 AA以上。すべてのインタラクティブ要素にキーボードサポート、フォーカス管理が必要で、セマンティックHTMLが不十分な場合はARIAが必要

API統合

• コンポーネントから直接APIを呼び出さない。データレイヤー（カスタムフック、サービス、クエリライブラリ）を使用する
• 3つの状態（ローディング、エラー、成功）を明示的に処理し、ハッピーパスを前提としない
• 変更時のユーザー体感パフォーマンス向上のために楽観的更新を使用する
• 境界でAPIレスポンスを検証する（Zod、io-ts、または同等のもの）— 外部データの形状を信頼しない
• APIのベースURLと認証トークンの注入を一元管理し、コンポーネント全体に分散させない

テスト戦略

3層アプローチ：

1. ユニットテスト：純粋関数、ユーティリティ、カスタムフック（Jest / Vitest）
2. コンポーネントテスト：レンダリング動作、ユーザー操作、状態変化（Testing Library — 実装ではなく動作をテストする）
3. E2Eテスト：重要なユーザージャーニーのみ（Playwright または Cypress）

ルール：

• 内部実装ではなく、ユーザーの視点から動作をテストする
• ロジックに対してスナップショットを使用しない — 脆弱。スナップショットは意図的な視覚的リグレッションにのみ使用する
• ビジネスロジックのカバレッジを高く、ボイラープレートは低くする
• テストファイルはテスト対象のコードと同じ場所に配置する：Button.test.tsx を Button.tsx の隣に置く

コードナビゲーション (tsserver)

テキスト検索を介した一般的なLSPワークフローは dev-standards スキル（「コードナビゲーション」）にあります。TypeScript固有の注意点：

LSP ツールはTS/TSXに対して tsserver にルーティングします。単一ファイルの操作（documentSymbol、hover、goToDefinition）はコールド状態でも信頼できます。

注意 — tsserver はインデックスを遅延して行います（goplsとは異なります）。 コールドサーバーに対して実行されるファイル間クエリ（findReferences/workspaceSymbol）は、過小カウントを静かに行う可能性があります：サーバーはプロジェクトにすでに読み込まれているファイルのみを認識し、自信はあるが不完全な結果（例：宣言のみ）を返します。これに対する防御策：

• 疑わしいほど少ない参照数は未確認として扱う。
• 使用箇所（シンボルをインポートしているファイル）から findReferences をクエリし、単独での宣言からは行わない — これによりプロジェクトグラフの読み込みが強制されます。
• 「これはまだどこかで使われているか？」という判断（デッドコード削除、安全なリネーム）には、grep で確認する — 過小カウントは危険です。

ツーリングのデフォルト (2025)

• バンドラ：Vite（新規プロジェクトのデフォルト）；すでに使用している大規模エンタープライズ環境ではWebpack 5
• リンター：ESLint + @typescript-eslint + Prettier（フォーマットはリンターと分離）
• パッケージマネージャー：モノレポではpnpm推奨；npmまたはyarnも許容
• モノレポ：マルチパッケージワークスペースにはNxまたはTurborepo
• CI：すべてのPRで型チェック、リンター、テスト、ビルドを実行する。赤いパイプラインをマージしない。

---

出力モード

出力を作成する際は、以下のガイドラインに従ってください：

コンポーネントコード：型を含め、エッジケースを処理し、スタックのパターンに従ってください（リファレンスファイルを参照）。サイズが許せない場合を除き、同じレスポンス内にコンポーネントとそのテストを提供してください。

アーキテクチャ / ファイル構造：最初にディレクトリツリーを示し、次にその理由を説明してください。意見を持ち、選択肢のメニューではなく、一つの良い構造を示してください。

パフォーマンス監査：重要度（Critical / Warning / Info）ごとに所見をリストアップしてください。各所見について：それは何か、なぜ重要か、どう修正するか。

デザインシステムのセットアップ：最初にトークン構造、次にコンポーネントプリミティブ、その後ドキュメンテーションのセットアップ。

API統合：特定のスタックのデータレイヤーパターンを示し、次にそれを利用するコンポーネントを示してください。

テスト：テスト対象のコードと共にテストを表示してください。AAA（Arrange / Act / Assert）に従ってください。

---

姉妹スキル

このスキルはエンジニアリングをカバーします。視覚的な美学（タイポグラフィの選択、色のシステム、モーションデザイン、空間構成、生成的な美学の回避）については、frontend-design スキルに委譲してください。両方が必要なタスク（例：「見栄えの良いダッシュボードを構築する」）では、両方のスキルを一緒に使用します：frontend-dev はアーキテクチャとコード品質を、frontend-design は視覚的な方向性を担当します。

リファレンスファイル

スタック固有の出力を生成する前に、以下を読み込んでください：

• references/typescript.md — TypeScript ストリクトモード、パターン、一般的な落とし穴
• references/react.md — React 19、Next.js、フック、状態管理、レンダリング戦略
• references/react-graphql.md — Relay、コロケーションされたフラグメント、React における GraphQL パターン
• references/angular.md — Angular v22、Signals、スタンドアロンコンポーネント、zoneless、NgRx