Communityライティング&編集github.com

FEコードレビュースキル

フロントエンドコードレビュー用の再利用可能なスキル。Quick、Deep、Fix Reviewの3つのモードを備え、Codex、Claude Code、Cursorで使用可能。

FEコードレビュースキル とは?

このスキルは、フロントエンドコードレビューを効率的かつ厳密に行うために設計された再利用可能なユーティリティです。Quick Review(デフォルト)、Deep Review(高リスク領域向け)、Fix Review(修正の再レビュー向け)の3つのモードを提供し、Codex、Claude Code、Cursorなどの主要なAIエージェントプラットフォームで動作します。Scope Discoveryメカニズムにより、未コミットの変更、ステージングされた変更、コミット、ブランチ/PRなど、レビュー対象の範囲を自動的に検出し、適切なベースラインと比較するための証拠を収集します。また、React、Vue、TypeScript、JavaScript、ハイブリッド/WebViewなどの技術スタックを自動検出し、プロジェクト固有の参照ファイルを読み込むことで、コンテキストに応じた正確なレビューを実現します。さらに、ブラウザランタイムの検証を条件付きで実行し、コードの静的解析だけでは確認できない動作を検証可能です。各モードでは、証拠収集の効率化と過剰な探索の抑制に関する厳格なルールが適用され、検出された問題にはトリガー条件、影響、根本原因、修正提案、検証方法が明確に説明されます。

対応✓Claude Code✓Codex CLI✓Cursor
npx skills add keykovar/skill-fe-code-review

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

FEコードレビュー

デフォルトルール

  • ユーザーの言語に合わせて応答する。ユーザーが中国語で書いた場合は簡体字中国語で応答する。
  • セクション見出し、ステータスラベル、推奨事項をユーザーの言語に翻訳する。有用な場合は英語のラベルを保持する。例:Blocking:必須修改。
  • 中国語のリクエストの場合、選択されたモードの中国語テンプレートを使用する。Overall Conclusion、Review Scope、Test Gaps、Final Recommendationなどの英語のみのセクション見出しは使用しない。
  • デフォルトは読み取り専用レビューとする。
  • ユーザーが明示的に要求しない限り、ファイルの変更、フォーマット、コミット、プッシュ、リセット、パッケージのインストール、ブランチの変更、破壊的なコマンドの実行を行わない。
  • レビュー、レビュー品質の評価、レビューレポートの出力を要求することは、チャット出力のみを許可する。ユーザーが明示的にファイル成果物やコード変更を要求しない限り、レポート、計画、TODO、Markdown、ソースファイルを作成または更新しない。Agent、Build、Write、または類似の名前のクライアントモードは、この境界を無効にしない。
  • 実際のコード、差分、コールパス、データフロー、パッケージバージョン、ランタイムコントラクトに基づいて所見を導き出す。
  • 名前だけでセマンティクスを推測しない。
  • 静的検査をランタイム検証として提示しない。
  • 曖昧な問題を報告しない。トリガー条件、影響、根本原因、修正提案、検証方法を説明する。
  • 明確な問題が見つからない場合は、その旨を直接述べ、残存リスクや未検証の領域をリストアップする。

スコープ発見

要求されたスコープを検査する。ユーザーが指定しない場合は、すべての未コミット変更をレビューする。インベントリは1回だけ収集する。

要求されたスコープがすべての未コミット変更である場合、許可されたスキル/ワークスペース境界内にscripts/collect-review-context.mjsが存在し、Node.jsが利用可能な場合は、個別のGitインベントリコマンドを発行する代わりにこれを実行する。

node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"

このスクリプトは読み取り専用であり、リポジトリルート、HEAD、ステータス、非ステージングの統計情報とパッチ、ステージングされたパッチ、追跡されていないファイル、git diff --check、CodeGraphの有無を返す。常に完全な未コミットのワーキングツリーを収集する。ステージングのみ、コミット、マージコミット、ブランチ、PR、範囲、パススコープのレビューでは実行しない。これらは要求されたスコープ外の変更を読み取るためである。それらのスコープには、一致する境界付きGitコマンドを使用する。すべての未コミットレビューの場合、コレクターの出力を再利用し、同等のコマンドを再実行しない。許可された境界内でスクリプトを実行できない場合は、クライアントがサポートする場合、読み取り専用のバッチで同じ証拠を手動で収集する。

git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard

レビュー前に比較ベースラインを確立して報告する。

  • 未コミット変更: HEADとワーキングツリーの比較(ステージング、非ステージング、関連する追跡されていないファイルを含む)。
  • ステージングされた変更: HEADとインデックスの比較。
  • コミット: その親とコミットの比較。
  • ブランチまたはPR: ユーザーが別の範囲を指定しない限り、マージベースとターゲットヘッドの比較。
  • マージコミット: ユーザーが別の親やベースラインを指定しない限り、最初の親とマージコミットの比較。

パッケージまたは設定ファイルが変更された場合は、依存関係とビルドへの影響を検査する。常に、要求されたスコープ、比較ベースライン、変更されたファイル、ステージングされたファイル、非ステージングファイル、追跡されていないファイル、実行されたかスキップされた検証コマンドを要約する。

Fix Reviewの場合、以前のレビューレポートまたは所見と修正差分も特定する。元の機能範囲を後の修正範囲から分離して保持する。

リポジトリルートに.codegraph/が存在し、CodeGraphが利用可能な場合は、広範なgrep/findの前にそれを使用してシンボル、コールパス、影響範囲を理解する。

証拠は次の順序で使用する。

  1. リポジトリソース、差分、コールパス、テスト、設定、ロックファイル、プロジェクトドキュメント。
  2. インストールされた依存関係のタイプと、解決されたローカルバージョンのソース。
  3. バージョンに敏感なフレームワークやライブラリの動作をローカルで確立できない場合にのみ、コードレビューを許可するツールコントラクトを持つ公式ドキュメント。

現在の公式Context7 MCPツールコントラクトはコードレビューを除外している。このスキルの実行中は、直接的または間接的にContext7を使用しない。これには、サブエージェント、デリゲート、プロキシ、ラッパー、または別のツールやセッションにレビューを委任して呼び出すことを含む。レビュー作業をドキュメント質問として再構成、分解、サニタイズ、またはリラベルすることで制限を回避しない。結論が外部セマンティクスに依存し、許可された信頼できる情報源が利用できない場合は、検証不可とマークし、不足している証拠を特定する。

外部ドキュメントサービスを使用する場合は、検証に必要な公開ライブラリ、バージョン、API、またはサニタイズされた動作の質問のみを送信する。プライベートソースコード、差分、リポジトリパス、内部APIデータ、認証情報、トークン、ユーザーデータ、専有識別子を決して送信しない。

条件付きブラウザランタイム証拠

次のすべての条件が満たされる場合にのみ、Playwrightまたは利用可能な他のブラウザ自動化ツールを使用する。

  • 変更された動作がブラウザで観測可能であり、ランタイム証拠が所見を実質的に確認または反駁できる場合。例:ルーティング、フォーム、非同期UI状態、ストレージまたはクッキーの動作、ハイドレーション、フォーカス、スクロール、レスポンシブオーバーフロー、リクエスト順序。
  • 具体的なエントリポイント(ローカルルート、URL、インタラクション、テストハーネスなど)が存在し、期待される観測可能な結果が要件、ベースライン動作、または既存のテストコントラクトから明確である。
  • 適切なローカルまたは分離されたテスト環境が、依存関係のインストール、プロジェクト設定の変更、生成されたアーティファクトのリポジトリへの書き込みなしにすでに実行可能である。
  • 初期状態が制御され、再現可能であり、本番データや実際のアカウントに依存せずに各実行前に再構築できる。
  • パスが分離されており、本番アクセス、実際の支払い、実際のユーザーデータ、破壊的なアクション、または不可逆的な外部副作用なしで実行できる。

ブラウザ検証は、リポジトリ、本番システム、実際のアカウントに対して読み取り専用に保つ。シナリオで必要な場合は、分離されたローカルブラウザ状態を変更してもよいが、実用的な場合はリセットし、その状態変更を製品データ検証として扱わない。

環境とURLタイプ、エントリポイント、ブラウザとビューポート、初期状態とその再現方法、期待される結果、アクション、観測された結果、関連するコンソールまたはネットワークの要約を記録する。認証情報、トークン、個人データ、リクエスト本文、機密性の高いレスポンスコンテンツをマスクする。ランタイム証拠が必要だが条件が満たされない場合は、検証不可を使用し、利用できない環境、状態、期待、または機能を記載する。

ブラウザ自動化は、記録された環境での実行パスのみを証明する。ブラウザチェックが成功しても、すべてのブラウザやビューポートでの動作を証明するものではなく、実際のWebView、ネイティブブリッジ、デバイス、バックエンド、デプロイ、監視、本番検証を置き換えるものではない。

モード選択

  • 日常的な変更、小規模なPR、バグ修正、ローカルリファクタリングには、デフォルトでQuick Reviewを使用する。
  • 支払い、認証、ルーティング/ナビゲーション、WebViewブリッジ、RTC/オーディオ/ビデオ、SSR/ハイドレーション、i18n、グローバルステート/ストア、キャッシュ/永続化、ビルド/デプロイ設定、依存関係のアップグレード、共有モジュール、パフォーマンスに敏感なコード、リリースブランチ、モジュール間の動作、大規模なリファクタリングにはDeep Reviewを使用する。
  • ユーザーが修正の再レビュー、以前の所見の検証、レビューコメントが解決されたかの確認、修正によって導入されたリグレッションの検出を要求する場合は、Fix Reviewを使用する。

レビュー前に正確に1つのモードリファレンスをロードする。

  • Quick Review: references/quick-review.md
  • Deep Review: references/deep-review.md
  • Fix Review: references/fix-review.md

Fix Reviewの場合、現在の会話からの以前の所見が利用可能な場合はそれを使用する。それ以外の場合は、ユーザーに以前のレビューレポート、問題リスト、または読み取り可能なパスを提供するよう要求する。使用可能なベースラインなしに、以前の所見を発明したり、問題が解決されたと主張したりしない。

技術検出

プロジェクトファイルを検査し、一致するリファレンスのみをロードする。

  • React: React、React DOM、Next.js、Remix、JSX/TSX、フックについてはreferences/react.mdをロードする。
  • Vue: Vue、Nuxt、Pinia、.vueファイル、Composition APIについてはreferences/vue.mdをロードする。
  • TypeScript: TypeScriptプロジェクトまたは変更されたTypeScriptコントラクトについてはreferences/typescript.mdをロードする。
  • JavaScript: JavaScriptプロジェクトまたはランタイムシェイプに依存するコードについてはreferences/javascript.mdをロードする。
  • ハイブリッド/WebView: ブリッジ、ネイティブコントラクト、WebView、アプリシェル、ストレージ、キーボード、セーフエリア、オーディオ、ビデオについてはreferences/hybrid-webview.mdをロードする。
  • リリースリスク: Deep Review、リリースブランチ、機能フラグ、ロールアウト、監視、ロールバック、高リスクフローについてはreferences/release-risk.mdをロードする。

Quick/Fix証拠規律

Quick ReviewとFix Reviewには、以下の必須実行ルールを適用する。これらは、必要なカバレッジを減らすことなく、繰り返しの探索を削減する。

  • クライアントがバッチ処理をサポートする場合、証拠グループごとに1つの境界付き読み取り専用ラウンドトリップを使用する。選択されたスキル/リファレンスファイル、初期コンテキストコレクターまたはその手動フォールバック、変更およびベースラインソースと直接のコンシューマー検索、残りの適用可能な検証。グループを分割するのは、管理できないほど大きな結果を防ぐ場合、または最初の結果が新しい未解決のコントラクトを明らかにした場合のみ。単にコマンド数を減らすためだけに、無関係な大きなファイルを連結しない。
  • 初期Gitインベントリを固定し再利用する。読み取り専用レビューでは、最後にステータス、名前ステータス、統計、ステージングされた差分、追跡されていないファイル、変更されていない差分のクエリを繰り返さない。ホスト評価者(レビューモデルではない)が、独立した実行後の整合性比較を実行する。
  • 選択された各指示、差分、ベースラインファイル、重複するソース範囲を1回だけ読む。必要な範囲をカバーする1つの行番号付き読み取りを優先する。繰り返しの読み取りや検索の前に、特定の未解決の証拠の質問を特定する。既存の出力がすでに回答している場合は、コマンドをスキップする。
  • 変更されたファイルと直接影響を受けるパスが判明した後は、.からの広範なrg検索やフィルタリングされていないrg --files/リポジトリファイルインベントリを実行しない。検索は、変更された所有者、名前付きシンボル、直接影響を受けるパスに限定する。具体的な一致が別のコンシューマーやコントラクトを明らかにした場合のみ拡大する。
  • 変更されたファイルタイプ、インポート、最大1つの関連するマニフェスト読み取りから技術を検出する。パッケージ、ロック、ビルド、TypeScript設定の詳細な検査は、それが変更された場合、または所見が解決されたバージョンやコンパイラ/ビルドコントラクトに依存する場合にのみ行う。汎用チェックリストを完了するためだけに、存在しない設定やロックファイルを調査しない。
  • 存在することがわかっているパスまたは1つの境界付きファイル名グロブクエリを使用して、直接関連するテストを1回検索する。その検索で適用可能なテストが確立されない場合は、ギャップを記録する。新しい証拠なしに、推測されるテストディレクトリ名やリポジトリ全体の別のパターンを再試行しない。
  • 同じ動作コントラクトを実行する独立した式または決定論的チェックを、1つの検証ラウンドトリップに結合する。最終的な説明を準備するためだけに差分を再実行しない。
  • ユーザーまたは評価者が、合成されたHEADが元の問題のベースラインを表すと明示的に宣言した場合は、現在のHEADと修正差分を検証し、その宣言されたベースラインを使用する。利用できない元のコミットオブジェクトを、クロージャがそれらに依存しない場合は各オブジェクトを調査する代わりに、証拠の制限として記録する。
  • 証拠が矛盾する場合、変更された条件が未分類のままである場合、直接影響を受けるコントラクトが未解決である場合、または所見にトリガーと影響がまだ欠けている場合は、これらのグループを超えて続行する。これらは、ハードなコマンドやトークンの上限ではなく、完全性ルールである。
  • 要求されたベースラインと差分が確立され、スコープ内のすべての変更された条件元帳エントリが考慮され、報告された各所見に十分な証拠があり、必要な検証が完了または明示的に境界付けられ、選択された出力コントラクトが一貫して満たされる場合、探索を停止する。主観的な信頼性を高めるためだけに検索を拡大しない。

Before/After動作分析

すべてのモードでこの分析を実行する。変更された行だけでなく、動作を比較する。

  1. 変更前の動作と変更後の意図された動作を特定する。
  2. 削除、弱体化、または意図せず保持された動作を検出する。
  3. 欠落しているブランチ、ガード、フォールバック、クリーンアップ、キャンセル、リトライ、エラーハンドリングを確認する。
  4. 所見に優先順位を付ける前に、要求された差分内の変更された決定ブロックで追加、変更、移動、分割、または保持されたすべての条件、ガード、フォールバック、デフォルト、早期リターンに対して、コンパクトな内部変更条件元帳を構築する。テキスト的に変更されていないガードでも、その周囲の制御フロー、リターン動作、またはステート書き込みが変更された場合は、スコープ内に残る。変更前と変更後で各ブランチがどのランタイム値を取るかを比較する。デフォルトでは元帳を出力しない。
  5. その元帳では、nullやundefinedなどの不在と、0、false、空文字列などの有効なfalsy値を区別する。それらのブランチの背後にあるステート書き込みについては、以前のtruthyまたは空でない値から、直接影響を受けるコンシューマーを通じて各有効なfalsy値への遷移をトレースする。現在の値だけを単独で検査しない。
  6. 確定する前にすべての元帳エントリを考慮する。動作を保持するもの、証拠ギャップ、所見として分類する。動作を保持するとして分類するのは、保持された動作自体が、可視のランタイムコントラクトとステート遷移に対して正しいことを確認した後でのみ行う。変更された決定ブロックが重要な欠陥を保持している場合は、それを報告し、差分によって導入されたリグレッションではなく、保持された欠陥として特定する。別の所見がより高い重大度を持つという理由だけで、影響を受ける変更条件を省略しない。
  7. 影響を受ける呼び出し元、コンシューマー、イベント、APIコントラクト、ストレージ、キャッシュ、ランタイムデータシェイプをトレースする。
  8. 動作を確認する

…

[切り詰められました]

関連スキル