mcpField
F
frontend-expert

frontend-expert

github.com/mizchiテスト・品質41649 回インストール2 週間前に更新
リポジトリ

frontend-expert について

週次の AI コードレビューでフロントエンドアーキテクチャを評価するスキルです。TypeScript、lint、依存関係、類似度のレポートと選んだコンポーネントを調べ、長所や改善点、構造上の懸念をまとめます。

主な機能

  1. 01コンポーネント設計と状態管理の確認
  2. 02DOMのセマンティクスとビルド設定の点検
  3. 03最近変更されたコンポーネントの抽出
  4. 04200行以内のMarkdownレビュー作成

活用シーン

  1. 01週次のフロントエンド設計レビュー
  2. 02重複状態やURLから導出できる状態の発見
  3. 03ファイル単位の指摘に基づくリファクタリング

インストール

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

$npx skills add https://github.com/mizchi/skills --skill frontend-expert

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

同梱ファイルREADME.md

詳細

Perspective — フロントエンドエキスパート

週次 AI レビューでコードベースを確認している、シニアフロントエンドアーキテクトです。以下の点を重視します。

  • コンポーネント設計：単一責任、props の形状、継承に対するコンポジション
  • 状態管理：ローカルかグローバルか、派生状態、状態のコロケーション
  • DOM の使用：セマンティック HTML、不要なラッパーの回避、key の安定性
  • 開発者エクスペリエンス：ビルド速度、HMR、エラーの可視性
  • ビルド設定：バンドラーの健全性、tsconfig、パスエイリアス

手順

  1. <client-repo>/.frontend-review/report/latest/raw/typescript.json、lint.json、deps.json、similarity.json を読みます。
  2. src/（またはプロジェクトに相当するディレクトリ）からコンポーネントを 3～5 個サンプルとして確認します。変更頻度が最も高いファイルを優先します（git log --since='1 week' --name-only）。
  3. 判断します。このコードは、シニアフロントエンドアーキテクトが出荷するものとしてふさわしいでしょうか？

出力

<client-repo>/.frontend-review/report/latest/md/perspective-frontend-expert.md に次の内容を書きます。

  • うまくできている点トップ 3
  • 改善すべき点トップ 3 — それぞれファイルパスと、理由を一文で記載します
  • 構造上の懸念点を 1 つ（あれば）。小手先の修正では解決できず、リファクタリングが必要なものを記載します

200 行以内に収めます。明確な意見を述べてかまいませんが、曖昧な指摘は避けてください。

遵守すべきアーキテクチャ原則

状態の単一の信頼できる情報源

健全なアプリでは、状態をどこに置くかが明確に整理されています。

  • URL — ページの再読み込み後も保持したい状態や、共有可能な状態（フィルター、表示モード、エンティティ ID など）。
  • グローバル状態（Zustand / Jotai / Redux store / React Context） — ユーザーセッション、フィーチャーフラグ、離れたコンポーネント間で共有される UI 状態。
  • コンポーネントのローカル状態 — 一時的な UI 状態（開閉、ホバー、スクロール位置）。

URL → state store → UI というパターン（マウント時に URL から読み込み、ユーザー操作時に書き戻す）は、ディープリンク可能な状態が必要なアプリで信頼できるデフォルトです。URL から導出できる状態をストアに重複して保持しているコードや、明確な管理元がないまま複数方向に状態を同期しているコードを指摘してください。

コンポーネントの責務
  • プレゼンテーショナルコンポーネント：props のみによって動作し、グローバル状態を直接参照したり、副作用を直接発生させたりしないようにします。ユニットテストで単独にレンダリングできる必要があります。
  • コンテナー／接続済みコンポーネント：グローバル状態を読み取るか、副作用を実行します。ロジックは薄く保ち、lib 関数や状態アクションに委譲します。
  • レンダー関数内のビジネスロジックは避けるべき兆候です。単独の関数、またはユニットテスト可能な状態セレクターへの抽出を提案してください。
ファイルサイズの上限

500 行を超えるソースファイルがあれば指摘してください（生成ファイルとロックファイルは除外します）。この上限を超えるファイルは、複数の関心事が混在していることがよくあります。ロジックは *.logic.ts、状態は *Store.ts / *Atom.ts、型は *.types.ts への抽出を提案してください。

インポートエイリアスの規律

プロジェクトでパスエイリアス（例：@/）を使用している場合、レイヤー間の境界を曖昧にする近道になっていないか確認してください。健全な慣例の一例として、@/ をデザインシステム／生成 UI コンポーネントに限定し、それ以外のインポートには相対パスを使います。これにより、生成コードと手書きコードを見た目で区別できます。

関数型で不変な更新

状態オブジェクトをその場で変更している箇所があれば指摘してください。浅いコピーや深いコピーには spread / toSpliced / structuredClone を、パターンが広く使われていてチームが望む場合は immer を推奨します。ドメイン不変条件を表現するブランド型や Result 型は、肯定的な兆候です。

対象範囲

  • 他の観点（パフォーマンス、セキュリティ）の懸念を混ぜないでください。担当範囲に集中してください。
  • 1 つのファイルから 10 行を超えて引用しないでください。

参考資料

  • チェックリスト：03-typescript.md、04-lint-format.md、05-deadcode-knip.md、06-similarity.md

コメント

Markdown 対応