frontend-code-review

フロントエンドコードレビューのスキル

目的

実践的な本番環境向けフロントエンド開発者の視点で、フロントエンドコードをレビューします。

このスキルは、エージェントが React／Next.js プロジェクトを調査し、曖昧な助言ではなく、役に立つ具体的なレビューコメントを返せるよう支援します。本番環境で実際に起こり得るリスク、ユーザーへの影響、保守性を優先します。

レビュー範囲

ユーザーの依頼に関連するコードまたは差分をレビューします。動作、契約、ユーザーへの影響を確認する必要がある場合に限り、隣接するモジュールも調査します。

単独のスニペットに関するルール

貼り付けられたスニペットをレビューする場合：

• ユーザーがリポジトリの文脈を踏まえたレビューを明示的に依頼しない限り、提供されたスニペットのみを使用します。
• プロダクト要件、フレームワークの文脈、ローカライズ要件、周辺の動作について推測しません。
• スニペットにフレームワークが示されていない限り、フレームワーク固有の考慮事項を持ち込みません。
• console.log、モックデータ、スタブなどのプレースホルダーらしいハンドラーは、ユーザーがスニペットを本番用コードの全体だと明言した場合に限り、確認済みの問題として扱います。それ以外の場合は、## Context-dependent considerations に記載します。
• 文脈に依存する懸念事項には、条件付きであることを明記します。
• 未確認の懸念事項は ## Context-dependent considerations に記載します。
• 条件付きの懸念事項を重大な問題に分類したり、マージを妨げる理由にしたりしません。
• 確認済みの問題がない場合は、Safe to merge based on the supplied snippet と返します。

基本的なワークフロー

1. レビュー対象の機能、ページ、コンポーネント、またはバグを把握します。
2. 指摘を行う前に、関連するコードを調査します。リポジトリをレビューする場合は、フレームワークの動作が関係する箇所について、package.json、next.config.*、隣接するモジュールを確認します。
3. 本番環境に影響する問題を優先して特定します。
4. フレームワークの境界を確認します：
   • React のレンダリングとフック
   • Next.js のサーバー／クライアントコンポーネント境界
   • データ取得とキャッシュの動作
   • ルーティング、メタデータ、リダイレクト、環境変数
   • サーバーアクション、ルートハンドラー、フロントエンドのセキュリティ境界
5. UI の品質を確認します：
   • 視覚的な階層
   • アクセシビリティ
   • モバイル対応／レスポンシブレイアウト
   • 読み込み中、空、エラーの各状態
6. 指摘事項を重大度ごとに分類します。
7. 各問題について、次の点を説明します：
   • 問題箇所
   • 問題の内容
   • 影響する理由
   • 修正方法
8. リポジトリのレビューでは、クリック可能なファイルと行への参照を含めます。貼り付けられたスニペットの場合は、コンポーネント、関数、または関連する式を参照します。
9. 有用な場合は、コードパッチを提示します。
10. 明らかに有害でない限り、既存のプロジェクトスタイルを尊重します。

レビューの原則

好みより正しさを優先する

主観的なスタイルの好みを重大な問題として指摘しないでください。

重大な問題とは、本番環境での障害、データ損失、セキュリティリスク、ユーザーの利用阻害、SEO への悪影響、深刻なアクセシビリティ上の問題を引き起こす可能性があるものです。

具体的な修正方法を優先する

悪い例：

エラー処理を改善してください。

良い例：

CreateJobForm は onSuccess だけを処理しています。リクエストが失敗するとユーザーにフィードバックがなく、繰り返し送信できてしまいます。onError を追加し、処理中は送信ボタンを無効にして、ユーザーが再試行できるようフォームデータを保持してください。

過剰な設計を避ける

本番環境で安全に使える、最小限の修正を推奨します。

クライアント／サーバーの境界を尊重する

サーバーコンポーネント内でクライアントフックを使うよう提案しないでください。

サーバーコンポーネント内でブラウザー API を使うよう提案しないでください。

インタラクティブ性が本当に必要でない限り、すべてを "use client" に移すよう提案しないでください。

useEffect の扱いに注意する

Effect は外部システムとの同期に使うものとし、派生状態やイベントロジックを置くデフォルトの場所として扱わないでください。

UI をプロダクトの動作として捉える

読み込み中、空、無効、エラーの各状態が欠けていることは、単なる見た目の問題ではありません。ユーザーを直接混乱させたり、操作の重複を引き起こしたりする可能性があります。

参考ファイル

関連する場合にのみ、以下のファイルを参照してください。

• references/checklist.md — 幅広いレビュー用チェックリスト。
• references/react.md — React のレンダリング、状態、ハイドレーション、フォームのルール。
• references/nextjs-app-router.md — 現行の Next.js 16 App Router のレビュー規則。
• references/data-fetching.md — TanStack Query と API クライアントのレビュー。
• references/frontend-security.md — XSS、認可、シークレット、ブラウザーセキュリティ。
• references/ui-ux-accessibility.md — UI、アクセシビリティ、レスポンシブデザイン。
• references/performance-seo.md — Core Web Vitals、メタデータ、リダイレクト、SEO。
• references/typescript.md — TypeScript のレビュー手法。
• references/i18n.md — 翻訳のフォールバック、ロケールルーティング、ローカライズされた SEO。
• references/output-format.md — 必須のレビュー出力形式。
• references/sources.md — このスキルの作成に使用した公式ドキュメント、ブログ、動画。
• examples/good-review.md — 具体的で重大度順に並んだレビューの例。
• examples/bad-review.md — 避けるべき曖昧なレビューコメントの例。

デフォルトの出力形式

ユーザーが別の形式を求めていない限り、以下の構成を使用してください。

## Critical issues

### 1. Issue title

**Where:** file/component/function

**Problem:** Explain the issue.

**Why it matters:** Explain production or user impact.

**Fix:** Give a direct fix. Include code if useful.

## Important improvements

Same format.

## Nice-to-have polish

Shorter, lower-severity suggestions.

## Summary

One short paragraph with the overall judgment.

## Suggested patch

Code examples or diff-style patches when useful.

## Final recommendation

Say one of:
- Safe to merge.
- Safe after fixes.
- Not safe to merge yet.

避けるべきこと

以下を避けてください。

• 曖昧なアドバイス
• 根拠のない主張
• 重要な問題としての、スタイルだけに関する細かな指摘
• SEO 上重要なルートに対するクライアントサイドリダイレクトの提案
• Server Components での TanStack Query フックの推奨
• ローディング、空、エラーの各状態を無視すること
• キーボードアクセシビリティを無視すること
• モバイルレイアウトを無視すること
• 小さな修正で十分な場合に、機能全体を書き直すこと