frontend-code-review

フロントエンドコードレビュー

このスキルを使用するタイミング

ユーザーが src/frontend/ ディレクトリ内のフロントエンドコード（.tsx、.ts、.js ファイル）のレビュー、分析、改善を依頼した場合は、必ずこのスキルを使用してください。次のレビュー方式に対応しています。

1. 変更保留中のレビュー -- コミット予定のステージ済みファイルまたは作業ツリー内のファイルを調べ、提出前にチェックリスト違反を指摘します。
2. ファイル指定レビュー -- ユーザーが指定したファイルをレビューし、該当するチェックリストの指摘事項を報告します。

次の場合はこのスキルを使用しないでください。

• バックエンドコード（src/backend/ 内の .py ファイル）に関する依頼である場合。
• ユーザーがフロントエンドコードのレビュー、分析、改善を依頼していない場合。
• 対象範囲が src/frontend/ の外である場合（ただし、ユーザーが別の場所にあるフロントエンド関連の変更をレビューするよう明示的に依頼した場合を除きます）。

このスキルの使用方法

このスキルを使用する際は、次の手順に従ってください。

1. ユーザーの入力に基づいて、レビュー方式（変更保留中またはファイル指定）を特定します。対象範囲を絞り、ユーザーが提示または明示的に参照した内容だけをレビューしてください。
2. チェックリストに定められたルールに従ってレビューを行います。該当するチェックリストのルールがない場合は、フォールバックとして一般的なレビューのルールを適用してください。
3. 必須の出力形式に厳密に従って最終出力を作成してください。

このスキルを使用する際の注意事項：

• 実行可能な修正案や提案（コードスニペットの候補を含む）を必ず提示してください。
• ファイルパスと行番号がわかる場合は File:Line 形式の参照を使用してください。それ以外の場合は、可能な限り具体的な識別子を使用してください。
• Langflow フロントエンドでは、React 19、TypeScript 5.4、SWC を使用した Vite 7、状態管理に Zustand、サーバー状態管理に TanStack React Query、グラフ表示に @xyflow/react v12、コンポーネントに Radix UI + shadcn-ui、Tailwind CSS v3、リントとフォーマットに Biome を使用しています。

チェックリスト

• コード品質：レビュー対象のすべてのファイルについて、references/code-quality.md に従い、スタイル規約、TypeScript の使い方、Biome への準拠、コンポーネントのパターンを確認します。
• パフォーマンス：レビュー対象に React コンポーネント、フック、Zustand ストア、React Query の使用、または @xyflow/react のノード描画が含まれる場合は、references/performance.md に従い、再レンダリングの問題、メモ化、データフローのパターンを確認します。
• ビジネスロジック：レビュー対象にカスタムノード（GenericNode）、フローの状態、API 呼び出し、コンポーネントシステム、グローバル変数、またはインスペクションパネルが含まれる場合は、references/business-logic.md に従い、Langflow 固有の正確性を確認します。
• i18n：差分にユーザー向けテキスト（ラベル、ボタン、ツールチップ、モーダル、トースト、エラー、プレースホルダー、aria-label）が追加または変更されている場合は、frontend-i18n スキルに従ってください。UI 文字列をハードコードせず、すべて t(...) を通し、新しいキーをすべてのロケールファイル（src/frontend/src/locales/*.json）に追加します。

一般的なレビューのルール

1. セキュリティレビュー

次の点を確認します。

• XSS の脆弱性（dangerouslySetInnerHTML、エスケープされていないユーザー入力）
• クライアント側コードからの機密データの漏えい
• API 呼び出しにおける安全でない直接オブジェクト参照
• ハードコードされたシークレット、トークン、API キー

2. アクセシビリティレビュー

次の点を確認します。

• インタラクティブ要素に aria ラベルが不足していないか
• キーボードナビゲーションに対応しているか
• セマンティック HTML 要素を適切に使用しているか
• カスタムスタイルにおける色のコントラストに問題がないか

3. コード品質のレビュー

以下を確認します。

• コードの重複（DRY 違反 — 3 回以上同じ使い方をしている場合は抽出します）
• 処理が多すぎる関数／コンポーネント（SRP 違反 — 説明に「および」が必要なら分割します）
• 深いネストや複雑な条件分岐（早期リターンとガード節を優先します）
• 名前付き定数を使用していないマジックナンバー／文字列
• 不適切な命名：汎用的な名前（data、result、temp）、関数名の動詞の接頭辞不足、ブール値の is／has／can／should 接頭辞不足
• エラーハンドリングやエラーバウンダリーの不足
• TypeScript の型カバー範囲の不足（any の使用や as any キャストがないこと）
• WHAT（何を）を説明していて WHY（なぜ）を説明していないコメント
• コメントアウトされたコード（バージョン管理を使用します）
• コンポーネントの動作を切り替えるブール値パラメーター（代わりに 2 つのコンポーネントを使用します）
• const やイミュータブルな代替手段があるのに、ミュータブルなパターンを使用している箇所
• 約 500 行を超える本番ファイル（600 行以上は要注意）
• 本番コード内の console.log（Biome が検出します）

4. テストへの影響のレビュー

以下を確認します。

• E2E テストを壊す可能性のある data-testid 属性の変更
• テストの更新が必要なコンポーネントインターフェースの変更
• data-testid 属性がない、新しいインタラクティブ要素

5. コミット前の検証

保留中の変更をレビューする場合、以下を検証します。

• npm run format（Biome フォーマッター）— 差分がゼロ
• npm run lint（Biome リンター）— エラーがゼロ
• npm test（Jest）— 失敗がゼロ

必須の出力形式

このスキルが呼び出された場合、応答は以下の 2 つのテンプレートのいずれかに厳密に従う必要があります。

テンプレート A（指摘事項がある場合）

# Code Review

Found <N> urgent issues that need to be fixed:

## 1. <brief description of issue>

FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix

<brief description of suggested fix with code example>

---

... (repeat for each urgent issue) ...

Found <M> suggestions for improvement:

## 1. <brief description of suggestion>

FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix

<brief description of suggested fix with code example>

---

... (repeat for each suggestion) ...

• 緊急の問題がない場合は、そのセクションを省略します。提案がない場合は、そのセクションを省略します。
• 問題の数が 10 を超える場合は、「緊急の問題 10 件以上」または「提案 10 件以上」と要約し、最初の 10 件のみを出力します。
• セクション間の空行を詰めず、読みやすさのためにそのままにします。
• テンプレート A を使用する場合（修正すべき問題がある場合）で、少なくとも 1 件の問題にコード変更が必要な場合は、構造化された出力の後に、提案した修正を適用するかどうかを尋ねる簡潔な質問を追加します。例：「これらの問題に対処するため、提案した修正を適用しますか？」

テンプレート B（指摘事項がない場合）

## Code Review

No issues found.