review-frontend

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

引数

• --parallel：エージェントがサブエージェントに対応している場合、技術領域ごとに並行してレビューを行うためのヒントです（ステップ 5 を参照）。対応していない場合は、同じ出力で順次レビューを実行します。
• パス：対象ディレクトリ（デフォルト：現在の作業ディレクトリ）

ステップ 1：変更されたファイルを特定する

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.(tsx?|jsx?|mjs|cjs|css)$|^(remix|vite)\.config\.'

ステップ 2：技術を検出する

# Detect Remix v2 (any official adapter). When matched, the Remix-specific
# surface is delegated to the review-remix-v2 skill in Step 4.
grep -E '"@remix-run/(react|node|cloudflare|deno|serve)"' package.json | head -3

# Detect React Flow
grep -r "@xyflow/react\|ReactFlow\|useNodesState" --include="*.tsx" -l | head -3

# Detect Zustand
grep -r "from 'zustand'\|create\(\(" --include="*.ts" --include="*.tsx" -l | head -3

# Detect Tailwind v4
grep -r "@theme\|@layer theme" --include="*.css" -l | head -3

# Check for test files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.test\.tsx?$'

ステップ 3：検証プロトコルを読み込む

コードについて実質的な判断を下す前に、review-verification-protocol スキルを読み込みます。

ステップ 5 に進む前の条件： スキルを読み込んでいる（または、そのチェックリストがコンテキスト内で開かれている）こと。ここでの条件が満たされるまで、重大度を分類したり、指摘事項を記述したりしないでください。

ステップ 4：スキルを読み込む

レビューする領域について、以下の該当する各スキル（SKILL.md を開く）を読み込み、ガイダンスをコンテキストに反映します。

Remix v2 の分岐（ステップ 2 で package.json に @remix-run/* が検出された場合）：

• review-remix-v2 を読み込みます。これは、6 つの Remix v2 領域のレビュー スキル（routing、data-flow、forms、error-boundaries、perf/SSR、meta+sessions）を読み込む包括的なオーケストレーターで、独自の検出テレメトリも備えています。Remix 固有の範囲に対して実行し、その指摘事項をこのレビューの出力にまとめてください。
• react-router-code-review も読み込むことはしないでください。Remix v2 は React Router v6 を基盤としていますが、Remix のルートモジュール規約に従ってルーティングします。このコンテキストでのルーティングは、包括的なスキルを通じて読み込まれる remix-v2-routing-review が対象とします。
• shadcn-code-review と、以下の条件付きスキルは引き続き読み込んでください。これらは Remix 層とは独立しており、ルーターにかかわらずコンポーネント、スタイリング、状態管理のコードに適用されます。

Remix 以外の分岐（デフォルト）：

• react-router-code-review
• shadcn-code-review

検出結果に基づいて条件付きで読み込むスキル（どちらの分岐でも適用）：

条件	スキル
@xyflow/react が検出された	react-flow-code-review
Zustand が検出された	zustand-state
Tailwind v4 が検出された	tailwind-v4
テストファイルが変更された	vitest-testing

ステップ 5：レビューする

エージェントがサブエージェントに対応しており（かつ --parallel が指定されている、または並行実行が適切な場合）、技術領域ごとにサブエージェントを 1 つずつ割り当てて並行実行します。それ以外の場合は、同じ領域を単一のコンテキストで順次レビューします。どちらの方法でも同じ出力が得られます。

並行実行の場合：

1. すべての技術を事前に検出する
2. 技術領域ごとにサブエージェントを 1 つずつ割り当て、それぞれがスキルを読み込んで担当領域をレビューする
3. すべてのサブエージェントからの結果を待つ
4. 指摘事項をまとめる

順次実行の場合：

1. 該当するスキルを読み込む
2. まず React Router のパターンをレビューする
3. shadcn/ui のパターンをレビューする
4. 検出された技術領域をレビューする
5. 指摘事項をまとめる

ステップ 6：指摘事項を検証する

問題を報告する前に：

1. 実際のコードを再読する（差分のコンテキストだけで判断しない）
2. 「未使用」と主張する場合は、すべての参照を検索しましたか？
3. 「欠落」と主張する場合は、フレームワークや親側での処理を確認しましたか？
4. 構文上の問題については、現行バージョンのドキュメントで検証しましたか？
5. 実際の問題ではなく、スタイル上の好みにすぎない指摘は削除する

重大または主要な問題として報告する前の条件： 該当する場合、その指摘について (2)〜(4) が具体的な根拠によって満たされていること。たとえば、FILE:LINE の形式で開いたファイル、参照を調べた grep／検索結果、引用した親側またはフレームワークのコードなどが必要です。差分のコンテキストだけでは不十分です。

ステップ 7：レビューの収束

単一パスでの網羅性

すべてのカテゴリ（スタイル、ロジック、型、テスト、セキュリティ、パフォーマンス）にわたるすべての問題を、1回のレビューですべて報告しなければなりません。後のラウンドに問題を持ち越さないでください。

指摘を提出する前に、次の点を自問してください。

• 「推奨した修正をすべて適用した場合、修正後のコードに新たな問題が見つかるでしょうか？」
• 「新しいコード（テスト、型、モジュール）を追加するよう求めていて、そのコード自体にもレビューが必要になるでしょうか？」

どちらかの答えが「はい」の場合は、作成者が一度にすべてに対応できるよう、想定される後続の問題も今回のレビューに含めてください。

スコープのルール

• 差分内のコードと、直接関連する既存コードのみをレビューしてください
• 差分より前には存在しなかった新機能、テスト基盤、アーキテクチャの変更を求めないでください
• テストカバレッジが不足している場合は、「X、Y、Z のテストカバレッジ不足」という 1 件の軽微な問題として指摘してください。モックライブラリ、動作の抽出、依存性注入のパターンなど、大幅な新規コードにつながる実装の詳細は指定しないでください
• 型仕様、ドキュメント、命名の問題は、公開 API の契約に影響しない限り軽微です
• 新しい依存関係（Mox、テストライブラリ、リンタープラグインなど）の追加を求めないでください

修正の複雑さに関する基準

既存コードの修正は、その規模にかかわらず、実際の重大度で指摘してください。

ただし、差分より前には存在しなかった新規コードの追加を求める場合は、情報提供として分類しなければなりません。

• 新しい依存関係（Mox、リンタープラグインなど）の追加
• まったく新しいモジュール、ファイル、テストスイートの作成
• 新しい動作、プロトコル、抽象化の切り出し

これらは、レビューのブロッカーではなく、今後の作業として作成者が検討する改善案です。

イテレーションポリシー

修正適用後の再レビューの場合：

• 以前に指摘した問題が適切に修正されたかどうかのみを確認してください
• 以前の指摘と無関係な新しい問題を挙げないでください
• 修正されていない軽微な問題や、あれば望ましい問題は許容し、再度指摘しないでください
• 再レビューの目的は検証であり、新たな問題の発見ではありません

出力形式

## Review Summary

[1-2 sentence overview of findings]

## Issues

### Critical (Blocking)

1. [FILE:LINE] ISSUE_TITLE
   - Issue: Description of what's wrong
   - Why: Why this matters (bug, a11y, perf, security)
   - Fix: Specific recommended fix

### Major (Should Fix)

2. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Minor (Nice to Have)

N. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Informational (For Awareness)

N. [FILE:LINE] SUGGESTION_TITLE
   - Suggestion: ...
   - Rationale: ...

## Good Patterns

- [FILE:LINE] Pattern description (preserve this)

## Verdict

Ready: Yes | No | With fixes 1-N (Critical/Major only; Minor items are acceptable)
Rationale: [1-2 sentences]

修正後の検証

修正適用後、次を実行してください。

npm run lint
npm run typecheck
npm run test

承認前に、すべてのチェックに合格する必要があります。

ゲート

順番に進めてください。条件を言い換えるだけで、合格条件を飛ばしてはいけません。

1. スコープを記録済み — 合格条件： このレビューの対象範囲を示すステップ 1 のコマンド出力（または明示的な代替のパス一覧）があること。
2. プロトコルとブランチのスキルを読み込み済み — 合格条件： review-verification-protocol と shadcn-code-review を読み込み済みであり、かつ、重大度を最初に判定する前に、(a) ステップ 2 で Remix v2 が検出され、review-remix-v2 を読み込み済み（react-router-code-review は読み込まない）、または (b) ステップ 2 で Remix v2 が検出されず、react-router-code-review を読み込み済みであること。
3. 条件付きスキル — 合格条件： ステップ 2 の検出項目（Remix v2、@xyflow/react、Zustand、Tailwind v4、テストファイル）ごとに、指定されたスキルを読み込むか、検出されなかったこと（どのコマンドで一致がなかったか）を記録していること。
4. 重大／高の根拠 — 合格条件： その種別の指摘に対するステップ 6 の合格ルールを満たす、ツリー内に存在する FILE:LINE を各該当指摘に記載していること。
5. 単一の出力 — 合格条件： Issues セクションの番号が連続しており、この成果物がステップ 7 の単一パスでの網羅性（問題の種別やレビューラウンドを持ち越さないこと）を満たしていること。

ルール

• レビューの前にスキルを読み込みます（レビュー後ではありません）
• すべての問題に連番を付けます（1、2、3...）
• 各問題にFILE:LINEを記載します
• Issue／Why／Fixを明確に分けます
• 実際の重大度に応じて分類します
• Next.jsのパターンを決めつけません（「use client」は使いません）
• 修正後に検証を実行します
• 問題はすべて1回のレビューで報告します。後の反復に持ち越しません
• 再レビューでは以前の修正のみを確認し、新たな問題を発見しません
• 新しいコード（新規モジュール、依存関係、テストスイート）の追加依頼は、ブロッキングではなくInformationalとして扱います
• VerdictではMinorとInformationalの項目を無視し、承認を妨げるのはCriticalとMajorのみです