自動コードレビュー
概要
このスキルは、実装完了時にプログラミングの原則と言語固有のベストプラクティスに基づいて自動的にコードレビューを実施します。変更されたコードを分析し、改善点を重大度別に分類して具体的な修正案とともに提示します。
いつ使うか
以下のタイミングでこのスキルを使用してください：
- •実装が完了し、コミット前にコード品質を確認したい時
- •Pull Request 作成前に品質チェックを実施したい時
- •ユーザーが「コードレビューして」「実装をチェックして」「品質を確認して」とリクエストした時
- •リファクタリング後に改善を検証したい時
いつ使うべきでないか
以下の状況ではこのスキルを使用しないでください：
- •設計段階やプランニング段階（実装前）
- •セキュリティ監査や脆弱性スキャン（専門的なセキュリティスキルで対応）
- •パフォーマンスプロファイリング（専門的なパフォーマンススキルで対応）
- •自動フォーマットのみが必要な場合（Prettier、Black などのツールを直接使用）
レビュー手順
1. 対象ファイルの特定
まず、レビュー対象のファイルを特定します。
引数が指定されている場合：
- •ファイルパスが指定された場合：そのファイルをレビュー対象とする
- •ディレクトリパスが指定された場合：そのディレクトリ内のすべてのソースファイルをレビュー対象とする
引数が指定されていない場合：
bash
git diff --name-only
を実行して、変更されたファイルを特定します。変更がない場合は、カレントディレクトリの最近編集されたファイルを対象とします。
2. ファイルの読み込みとコンテキスト理解
各対象ファイルに対して以下を実行：
- •Read ツールでファイル全体を読み込む
- •ファイルの目的と役割を理解する（コメント、関数名、クラス名から推測）
- •プログラミング言語を拡張子から特定する（
.js、.py、.swift、.go、.rs、.javaなど） - •ファイルの構造と依存関係を分析する
3. プログラミング原則のチェック
programming-principles.md を参照し、以下の原則に基づいてコードをレビューします：
確認項目
- •
SOLID 原則
- •単一責任の原則：各クラス/関数が1つの責任だけを持っているか
- •オープン・クローズドの原則：拡張に開かれ、変更に閉じているか
- •リスコフの置換原則：派生型が基本型と置換可能か
- •インターフェース分離の原則：クライアントが使わないメソッドに依存していないか
- •依存性逆転の原則：抽象に依存し、具象に依存していないか
- •
DRY（Don't Repeat Yourself）
- •重複したコードブロックがないか
- •共通化できるロジックがないか
- •マジックナンバーやマジックストリングが定数化されているか
- •
KISS（Keep It Simple, Stupid）
- •不必要に複雑な実装になっていないか
- •より簡潔に書ける箇所はないか
- •ネストが深すぎないか（3階層以上は要注意）
- •
YAGNI（You Aren't Gonna Need It）
- •現在使われていない機能がないか
- •将来の拡張を想定した過剰な抽象化がないか
- •
関心の分離
- •ビジネスロジックとUI が分離されているか
- •データアクセス層が適切に分離されているか
- •
早期リターン・ガード節
- •エラーケースを早期に return しているか
- •深いネストを避けるためにガード節を使用しているか
4. 言語固有のベストプラクティスチェック
language-best-practices.md を参照し、言語に応じた以下のチェックを実施します：
JavaScript/TypeScript
- •
const/letの適切な使い分け（varの使用を避ける） - •
async/awaitの適切な使用（Promise の適切なエラーハンドリング） - •型安全性（TypeScript の場合、
anyの使用を避ける） - •不変性（配列やオブジェクトの直接変更を避ける）
- •アロー関数と通常関数の適切な使い分け
Python
- •PEP 8 スタイルガイドの遵守（命名規則、インデント、空白）
- •リスト内包表記の活用
- •コンテキストマネージャ（
with文）の使用 - •型ヒントの適切な使用（Python 3.5+）
- •例外処理の適切性（bare except の回避）
Java
- •
Optionalの適切な使用（null チェックの代替） - •Stream API の活用
- •
try-with-resourcesの使用（リソース管理） - •適切な例外処理（チェック例外 vs 非チェック例外）
Swift
- •Optional の安全な扱い（forced unwrap
!の回避） - •プロトコル指向プログラミング
- •メモリ管理（strong、weak、unowned の適切な使用）
- •
guard文の活用
Go
- •エラーハンドリングの徹底（エラーを無視しない）
- •
deferの適切な使用（リソースのクリーンアップ） - •インターフェースの小さく保つ設計
- •goroutine の適切な管理
Rust
- •所有権と借用の適切な使用
- •
Result型によるエラーハンドリング - •パターンマッチングの活用
- •
unwrap()の使用を避ける（本番コードでは）
5. レポート生成
以下の形式で構造化されたレポートを生成します：
markdown
# コードレビューレポート 生成日時: [YYYY-MM-DD HH:MM:SS] ## サマリー - レビューファイル数: X ファイル - Critical: Y 件 - Warning: Z 件 - Suggestion: W 件 --- ## ファイル名：path/to/file.ext ### Critical（重大な問題） コードの動作に問題があるか、バグを引き起こす可能性が高い問題 - **問題点**：[具体的な問題の説明] - **該当箇所**：行 XX-YY ```language [該当コード]
- •理由：[なぜこれが問題なのか]
- •修正案：
language
[修正後のコード例]
Warning（警告）
コードの保守性や可読性に影響する問題、潜在的なバグの可能性
- •問題点：[具体的な問題の説明]
- •該当箇所：行 XX-YY
language
[該当コード]
- •理由：[なぜこれが問題なのか]
- •修正案：
language
[修正後のコード例]
Suggestion（提案）
より良い実装方法や最適化の提案
- •提案内容：[改善案の説明]
- •該当箇所：行 XX-YY
language
[現在のコード]
- •期待される効果：[この変更による利点]
- •修正案：
language
[修正後のコード例]
総評
[全体的な評価とコメント]
code
## レポートの重大度分類基準 ### Critical（重大な問題） 以下のいずれかに該当する問題： - メモリリーク、リソースリークの可能性 - null/undefined 参照エラーの可能性 - 無限ループやスタックオーバーフロー - セキュリティ上の重大な脆弱性 - データ損失の可能性 ### Warning（警告） 以下のいずれかに該当する問題： - SOLID 原則の違反 - 明らかなコードの重複（DRY 違反） - 過度に複雑な実装（KISS 違反） - エラーハンドリングの不足 - 命名規則の不統一 - 保守性を低下させる実装 ### Suggestion（提案） 以下のいずれかに該当する改善案： - パフォーマンスの最適化 - より読みやすい実装方法 - 言語の新機能の活用 - コードの簡潔化 - より適切なデザインパターンの提案 ## 注意事項 ### False Positive の可能性 - すべての指摘が必ずしも適切とは限りません - コードのコンテキストによっては、意図的な設計の場合もあります - 最終的な判断はユーザー（開発者）に委ねられます ### コンテキストの重要性 - ファイル単体ではなく、プロジェクト全体のコンテキストを考慮します - 既存のコードスタイルやプロジェクトの方針を尊重します - チームの合意されたコーディング規約がある場合、それを優先します ### テストコードの扱い - テストコードは一部の原則（DRY など）を緩和する場合があります - 可読性と明確性をより重視します - テストの独立性を保つため、意図的な重複を許容する場合があります ## レビューのカスタマイズ プロジェクト固有のルールやチーム規約がある場合は、レビュー実行前にそれらを明示してください。カスタムルールに基づいたレビューも可能です。 例： - 「このプロジェクトでは hooks を使用せず、class component を使用する方針です」 - 「命名規則として、private メソッドには `_` プレフィックスを付けています」 - 「このファイルはレガシーコードで、現在リファクタリング中です。新しい実装パターンのみレビューしてください」