review

レビュー

概要

このスキルを使用して、現在の Git ワークスペースでコミットされていない変更をレビューします。
正確性、安全性、保守性、プロジェクト標準との整合性に注目します。

レビューでは、次の内容を提示する必要があります。

1. 変更内容の簡潔な要約
2. 重大度ラベル付きの優先順位順の指摘事項
3. 実行可能な修正案
4. 最終判定（Approve または Request Changes）

ワークフロー

ステップ 1：コンテキストの収集

1. 現在の変更を確認します。
   • git diff
   • ステージされた変更がある場合は git diff --cached
2. 周辺のロジックやアーキテクチャを理解するため、変更されたファイル全体を読みます（差分の該当箇所だけではなく、ファイル全体を読みます）。
3. スタイルやパターンを判断する前に、変更されたファイルに関連するプロジェクトのコンテキストだけを読み込みます。
   • docs/SUMMARY.md がある場合は、最初に読みます。
   • タスクに関連する詳細ドキュメントだけを読み込みます。
   • 実装規約については、Code Standard ドキュメントを優先します。
   • ドキュメントがコードやユーザーの意図と矛盾する場合は、広範な変更を行う前に、利用可能な入力／質問ツールを使用します。
4. 該当箇所に関連する品質チェックを実行します（可能であれば、リンター、型チェック、テストを実施します）。

ステップ 2：変更の分析

各変更を次の観点から評価します。

1. 正確性 - 動作は意図された要件を満たしていますか？
2. 安全性とセキュリティ - 脆弱性、データ漏えい、認証の不備、安全でない前提はありませんか？
3. 信頼性 - エッジケース、null 状態、再試行、エラー処理に対応していますか？
4. スタイルと一貫性 - コードはプロジェクトの規約や既存のパターンに従っていますか？
5. パフォーマンス - 不必要にコストのかかる処理やパフォーマンスの低下はありませんか？
6. テスト - 重要な経路が適切なテストでカバーされていますか？
7. 保守性 - コードは明確で、モジュール化され、変更しやすいですか？

ステップ 3：指摘事項の重大度を分類

次の基準を使用して、指摘事項ごとに重大度を割り当てます。

• S0 - 重大

  • 本番環境を停止させる問題、深刻なセキュリティリスク、データの破損／損失、または取り消せない副作用
  • マージ前に必ず修正する必要があります

• S1 - 高

  • 発生可能性の高いバグ、正確性の問題、重大な信頼性の問題、または重要な検証の欠如
  • マージ前に修正する必要があります

• S2 - 中

  • ブロッカーではありませんが、保守性、パフォーマンス、明瞭さに影響する有意な問題
  • 早めの修正を推奨します

• S3 - 低

  • 軽微な改善、仕上げ、またはスタイル上の提案
  • チームの標準で必須とされていない限り、任意です

ステップ 4：構造化されたレビューレポートの作成

以下のレポート形式を、指定されたセクション順で正確に使用します。

出力形式

1) 要約

• 変更内容（箇条書き 2～6 項目）
• リスクの程度（低／中／高）
• レビューした領域（ファイル／モジュール）

2) 指摘事項

各指摘事項には、次のテンプレートを使用します。

• ID: R-001（連番）
• 重大度: S0 | S1 | S2 | S3
• カテゴリ: Correctness | Security | Reliability | Style | Performance | Testing | Maintainability
• 場所: path/to/file.ext#Lx-Ly（または関数／クラス名）
• 問題: 問題を明確に記述します
• 重要な理由: ユーザー／システムへの影響
• 提案: 具体的な修正方針
• 確信度: High | Medium | Low

指摘事項がない場合は、対応が必要な指摘事項はありません と明記します。

3) 良い点

確認できた優れた実践例を挙げます。たとえば、次のようなものがあります。

• テストカバレッジの追加
• 適切な関心の分離
• 工夫されたエラー処理
• 一貫したスタイルと命名

4) 必須修正チェックリスト

S0 と S1 の指摘事項のみを含めます。

• R-00X 修正内容の簡潔な説明
• R-00Y 修正内容の簡潔な説明

該当する項目がない場合は、必須修正項目はありません と記載します。

5) 判定

次のいずれかを使用します。

• Approve - ブロッキングな問題（S0/S1）は残っていません。
• Request Changes - 1 件以上のブロッキングな問題（S0/S1）があります。

必要に応じて、次の項目を含めます。

• 再レビューの重点箇所: 修正後に再確認するファイル／領域

ルール

• 具体的に指摘し、可能な限り正確な箇所を示してください。
• コードを切り離して評価せず、必ず周辺の文脈を考慮してください。
• 曖昧な批判よりも、実行可能な提案を優先してください。
• ブロッキングなフィードバックと、ブロッキングではないフィードバックを明確に区別してください。
• 推測に基づく主張は避けてください。不確かな場合は確信度を下げ、その理由を説明してください。
• フィードバックは、プロジェクトのドキュメントとコーディング規約に沿ったものにしてください。

レビュー品質チェックリスト

最終確認の前に、次の点を確認してください。

• 変更されたすべてのファイルを、文脈を踏まえてレビューした
• 各指摘に、重大度、影響、修正案が含まれている
• ブロッキングな問題を、必須修正のチェックリストとして分けている
• 最終評価が、指摘の重大度と一致している
• フィードバックが簡潔で、正確で、実行に移せる内容になっている