code-review

コードレビュー

中国語版： 対応する中国語スキルを参照してください。

使用する場面

• PR／差分／コミットをレビューし、マージ前にロジック、セキュリティ、金銭的損失、保守性に関するリスクを見つける必要がある場合。
• 場所と実行可能な修正方針を含む、P0／P1／P2 の優先度別レポートが必要な場合。
• 作成者によるセルフレビューに加えて、QA／エンジニアリング品質の観点が必要な場合。

ワークフロー

1. Progressive disclosure に記載されたメインプロンプト（網羅範囲、構成、品質基準）を読み、それに従います。
2. レビューの前に、特定可能なコードのバージョンとレビュー可能な変更の両方があることを確認します。どちらかが欠けている場合は、ブロックされた結果を返し、正確な資料を求めます。
3. 結果に影響するプロジェクトのコンテキストのみを追加します。変更範囲、ビジネス目標、技術スタック、上流／下流の依存関係、既知のリスク、チームの規範などです。
4. ロール別レポートは、出典が明記された任意のコンテキストとして扱います。Product および UI/UX のレポートは、今回の変更がそれらに関係する場合にのみ使用します。
5. 既定では Markdown を使用し、ユーザーから求められた場合にのみ形式を切り替えます。

主な制約

• リスクを重視します。本番環境での障害、金銭的損失、セキュリティ、コアな保守性を優先し、命名やインデントのノイズは優先しません。
• 根拠に基づきます。各指摘には、発生条件と影響に加え、ファイルパス、行、またはコードスニペットを示すことを優先します。
• 2 つのゲートがあります。特定可能なコードのバージョン（例：リポジトリ＋PR／コミット／ブランチ／タグ／リビジョン）と、レビュー可能な変更（例：差分／パッチ、変更ファイルの内容、またはアクセス可能な base-to-head の範囲）の両方が必要です。コードの特定情報、変更内容、ロール別レポートは、互いの代わりにはなりません。
• どちらかのゲートが欠けている場合は、status: blocked を明示的に返し、missing_code_identity と missing_reviewable_change を区別します。レビューが完了したと主張したり、マージを推奨したり、コードに関する指摘を捏造したりしてはいけません。
• ロール別レポートは任意です。使用する場合は source_role を保持します。Product のレポートではビジネスルール、状態遷移、受け入れ条件に関するコンテキストを補足できます。UI/UX のレポートでは、関連する場合に限り、UI の状態、フィードバック、レスポンシブ対応、アクセシビリティに関するコンテキストを補足できます。ロールの観点をコード上の事実として提示してはいけません。
• 重要度は厳密に判定します。P0 はマージをブロックし、P1 は今回のイテレーションで修正すべきで、P2 は技術的負債として扱えます。
• 確認済みの事実と仮定を分けます。ユーザーから提供されていないエンドポイント、フィールド、環境、根本原因を捏造してはいけません。
• 作成者ではなくコードを批評し、現在の技術スタックを尊重します。許可なくフレームワークやアーキテクチャの書き換えを要求してはいけません。
• 出力は実行可能なものにします。すべての指摘に、修正方針または修正前／修正後の例を含めます。

Progressive Disclosure

• 出力する前に、prompts/code-review.md を読み、そこに記載された要件（最低限の網羅範囲、出力構成、品質基準）に従います。
• Excel／CSV／JSON／Word が求められた場合は、output-formats.md を読み、指定形式を守ります。
• 既成のテンプレートが適している場合は、output-templates/ 内の該当ファイルを使用します。
• より深いレビュー観点や重要度基準については、references/review-dimensions.md を読みます。
• 例や評価基準の調整については、examples/ 内の該当ファイルを読みます。
• 形式変換や補助チェックには、新たに作り直すのではなく、既存の scripts/ を優先して使用します。
• 最短の手順については、quick-start.md を読みます。
• このスキルの評価や回帰テストには、skill-up とともに evals/ を使用します。

提出前チェックリスト

• メインプロンプトの出力構成に従った
• コードの特定情報とレビュー可能な変更の両方のゲートを確認した。ブロックされた場合は、レビュー完了の報告やマージ推奨をしていない
• 最低限の網羅項目を確認した：変更概要、全体的なリスク評価、P0／P1／P2 の一覧、テスト可能性／可観測性、API／契約の互換性、修正順序、残存リスクと仮定…（詳細はメインプロンプトを参照）
• 最低限のチェックリストを網羅したか、省略した項目について説明した
• 高リスク項目に、根拠を添えて P0／P1 の重要度を明示した
• ユーザーから提供されていない詳細を捏造していない
• 仮定と不足事項を明記した

よくある落とし穴

• コードスニペットや役割レポートをコードの識別情報として扱ったり、PR／コミット識別子を差分として扱ったりしないでください。いずれかのゲートが欠けている場合は、先に進まないでください。
• レポートがあるというだけで、プロダクトや UI／UX に関する懸念を取り上げないでください。まず関連性を確認し、情報源を保持してください。
• すべての項目を同等に重要なものとして扱ったり、価値の低いスタイル上の指摘を大量に挙げたりしないでください。
• 前提や情報の不足を見落とさないでください。
• レビュー対象の変更範囲外のリファクタリングを強制しないでください。
• この変更に関係のない一般論を大量に挙げないでください。