frontend-review

フロントエンドコードレビューガイドライン

このスキルは、React / TypeScript で書かれたフロントエンドコードの変更点（Diff）をレビューする際の手順、自動検証コマンド、および目視レビュー用チェックリストを提供します。

1. レビューの流れ

フロントエンド関連のファイル（frontend/ 配下）に変更があった場合、以下の手順でレビューを実施してください。

1. 自動ツールの実行による前提検証:
   • フロントエンドのディレクトリでリンターおよびフォーマットチェック（Biome）を実行します：

     task lint
     

   • E2Eテスト（Playwright）を実行します：

     # もしくは cd frontend && npx playwright test
     # ※Wailsが起動していない状態でも、モックを使用して実行可能です
     # コマンドは環境に合わせて実行してください
     task test:e2e
     

   • もし自動ツールでエラーが発生した場合は、その修正案も指摘事項に含めます。
2. 差分（Diff）の取得:
   • git diff（またはステージング済みの差分を確認する git diff --cached や、特定のブランチと比較する git diff origin/main など）を実行して変更差分を取得します。
3. 変更全体の把握:
   • どのコンポーネント、スタイル、あるいはE2Eテストコードが追加・変更されたかを把握します。
4. 差分の目視レビュー:
   • 取得した差分に基づき、後述のレビューチェックリストに照らし合わせてコードを1行ずつ精査します。
5. 指摘事項の整理:
   • ルール違反や改善の余地がある箇所について、改善案となる「具体的な修正コード例」を合わせて作成します。
6. レビュー結果の報告:
   • 後述の出力テンプレートに従い、結果をユーザーに報告します。

2. レビューチェックリスト

2.1 アーキテクチャと構造（プロジェクトルール）

• HashRouterの強制: デスクトップアプリ（Wails）のファイルプロトコル制限に対応するため、BrowserRouter ではなく必ず HashRouter が使用されているか。
• コンポーネントの配置: UIコンポーネントは frontend/src/components/ui/ 配下に機能ごとのディレクトリ（例: Toolbar/Toolbar.tsx）を作って配置されているか。
• Wails IPC通信: バックエンドの呼び出しには frontend/wailsjs/go/ 内の自動生成バインディングを使用し、これらを直接手動で編集していないか。
• 状態管理の制限: 標準の Hooks/Context または軽量な Zustand のみが使用されているか（ReduxやMobXなどの重量フレームワークが導入されていないか）。

2.2 スタイリングとデザイン（プロジェクトルール）

• CSS Modulesの適用: コンポーネント固有のスタイルは CSS Modules（*.module.css）として同一ディレクトリに配置されているか。
• クラス名の命名規則: CSS Modules 内のクラス名はキャメルケース（例: styles.listPage）になっているか。
• CSS変数の徹底利用: 色や背景などの指定に、frontend/src/styles/variables.css で定義された変数が使用されているか（ハードコードされたカラーコード、例: #30363d 等の生の値が残っていないか）。
• テーマ対応: body.light-theme の有無によるライト・ダークテーマ切り替えが考慮されているか。
• Vanilla CSSの遵守: ユーザーの明示的な指示がない限り、Tailwind CSS 等の外部ユーティリティファーストフレームワークが導入されていないか。

2.3 コードスタイルとBiome（プロジェクトルール）

• インデントとクォート: インデントに タブ (Tab)、文字列に ダブルクォート (") が使用されているか（Biome の設定に合致しているか）。
• 非nullアサーション（!）の禁止: TypeScriptの ! アサーションによるランタイムクラッシュのリスクを避け、オプショナルチェイニング（?.）や安全な存在チェック（if）で対応しているか。
• フック依存配列の厳格化: useEffect, useMemo, useCallback 等の依存配列に必要な変数が漏れなく指定されているか。また、不要な再生成を防ぐため useCallback / useMemo が適切に活用されているか。
• アクセシビリティ（a11y）の対応:
  • ボタン要素に type 属性（type="button" など）が指定されているか。
  • SVG要素に代替テキスト（<title>）が含まれているか。
  • クリックイベントを持つ div 等の非対話的要素に tabIndex および onKeyDown が適切に指定されているか。
• !important の禁止: CSS内で !important を使用せず、詳細度を制御してスタイリングしているか。

2.4 TypeScript/React品質向上（一般ルール）

• any 型の原則禁止: 意図しない型安全性の破壊を防ぐため、原則として any を使用せず、適切なインターフェースやジェネリクス、または unknown を使用しているか。
• useEffect のクリーンアップ処理: useEffect 内で登録したイベントリスナー、タイマー（setTimeout, setInterval）、あるいは非同期リクエストのキャンセル処理などのクリーンアップ（return 関数）が適切に行われているか。
• 不要な再レンダリングの防止: パフォーマンスに影響を及ぼす重い処理や、子コンポーネントへのコールバック/オブジェクトの引き渡しにおいて、useCallback や useMemo が適切に使用されているか。

2.5 E2Eテストとモック（プロジェクトルール）

• テストコードの配置: Playwrightテストコードが frontend/tests/e2e/ 配下に機能ごとに分割して配置されているか。
• Wails APIのモック化: 新しいWails APIの呼び出しを追加した場合、frontend/tests/e2e/helpers/mock-wails.ts にも適切なモックが追加・更新されているか。
• コードとテストの同期: UIやAPIバインディングの変更と同時に、同一のコミット/PR内でテストおよびモックコードが更新されているか。

3. レビュー結果の出力テンプレート

レビュー結果を報告する際は、以下のフォーマットをそのまま適用して出力してください。

# フロントエンドコードレビュー結果

## 概要
[ここにレビュー対象のブランチ/コミット/変更内容の全体的な要約を記述。自動検証ツール（Biome/Playwright）の実行結果もここに記述]

## 指摘事項
[問題が見つからなかった場合は「指摘事項はありません」と記述]

### 1. [指摘カテゴリ（例: スタイリング、Biomeルール違反、TypeScript品質など）]
*   **ファイル**: [ファイル名と行数へのリンク（例: frontend/src/components/ui/Toolbar/Toolbar.tsx#L25-L30）]
*   **問題点**: [何がルールに違反しているか、なぜ修正すべきかの理由]
*   **修正コード例**:
    ```tsx
    // [ここに修正後の具体的なコード例]
    ```

---
[必要に応じて指摘事項を繰り返します]