コードレビュー スキル

diff に対する包括的なコードレビューを実行しています。変更されたコードのセキュリティ脆弱性、アンチパターン、品質の問題を分析するのが目的です。

入力モデル

このスキルは、実行前に文脈内で diff が提供されることを想定しています。diff の生成は呼び出し側の責任です。

実行例：

• ユーザーが PR diff を貼り付けてから /code-review を実行
• エージェントが git diff HEAD~1 を実行してからこのスキルを呼び出す
• CI ツールが レビュー用に diff コンテンツを提供

文脈に diff がない場合は、ユーザーに提供するよう依頼するか、生成を提案してください（例：git diff、git diff main..HEAD）。

---

ドメイン検出

diff 内のディレクトリパスに基づいて、適用するチェックリストを自動検出します：

ディレクトリ	ドメイン	チェックリスト
designer/	フロントエンド	frontend.md を読む
server/	バックエンド	backend.md を読む
rag/	バックエンド	backend.md を読む
runtimes/universal/	バックエンド	backend.md を読む
cli/	CLI/Go	汎用チェックのみ
config/	設定	汎用チェックのみ

diff が複数のドメインにまたがる場合は、関連するすべてのチェックリストを読み込みます。

---

レビュープロセス

ステップ1：Diff を解析

diff から以下を抽出します：

• 変更されたファイルのリスト
• 変更された行（追加と修正）
• ファイルパスに基づいて検出されたドメイン

ステップ2：レビュードキュメントを初期化

temp-files パターンを使用してレビュードキュメントを作成します：

SANITIZED_PATH=$(echo "$PWD" | tr '/' '-')
REPORT_DIR="/tmp/claude/${SANITIZED_PATH}/reviews"
mkdir -p "$REPORT_DIR"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
FILEPATH="${REPORT_DIR}/code-review-${TIMESTAMP}.md"

このスキーマで初期化します：

# コードレビュー レポート

**日付**: {現在日時}
**レビュアー**: Code Review Agent
**ソース**: {例：「PR diff」、「未ステージの変更」、「main..HEAD」}
**変更されたファイル**: {数}
**検出されたドメイン**: {リスト}
**ステータス**: 進行中

## サマリー

| カテゴリ | チェック済み | 成功 | 失敗 | 検出事項 |
|---------|----------|------|------|--------|
| セキュリティ | 0 | 0 | 0 | 0 |
| コード品質 | 0 | 0 | 0 | 0 |
| LLM コードの匂い | 0 | 0 | 0 | 0 |
| インパクト分析 | 0 | 0 | 0 | 0 |
| 簡潔化 | 0 | 0 | 0 | 0 |
{検出されたドメインに基づいてドメイン固有のカテゴリを追加}

## 詳細な検出事項

{レビューが進むにつれて検出事項をここに追加}

ステップ3：変更されたコードをレビュー

チェックリストのアイテムごとに：

1. フィードバックを diff 行のみにスコープする - 変更されたコード内の問題のみをフラグします
2. ファイル文脈を使用する - 完全なファイルコンテンツを読んで周囲のコードを理解します
3. 関連チェックを適用する - ドメインに適切なチェックリストアイテムを使用します
4. 検出事項を文書化する - 変更されたコード内で見つかった各違反を記録します

重要な原則：diff がレビュー対象です。ファイルの残りの部分がそのレビューを正確にするための文脈を提供します。

ステップ4：インパクト分析

diff がコードベースの他の部分に影響を与える可能性があるかをチェックします：

• 変更されたエクスポート/インターフェース - 他の場所での使用を検索して破壊がないか確認
• 変更された API シグネチャ - 更新が必要な呼び出し元をチェック
• 変更された共有ユーティリティ - 影響を受ける可能性のあるコンシューマーを探す
• 設定/スキーマの変更 - 古い構造に依存するコードを見つける

考慮されていないインパクトを検出事項として報告し、リスクに基づいて重大度を記載します。

ステップ5：各検出事項を文書化

見つかった問題ごとに、エントリを追加します：

### [{カテゴリ}] {アイテム名}

**ステータス**: 失敗
**重大度**: 致命的 | 高 | 中 | 低
**スコープ**: 変更されたコード | インパクト分析

#### 違反

- **ファイル**: `path/to/file.ext`
- **行番号**: 42-48（diff から）
- **コード**:

// diff からの問題のあるコードスニペット

- **問題**: {何が間違っているかの説明}
- **推奨事項**: {修正方法}

ステップ6：レポートを完成させる

すべてのチェックを完了した後：

1. サマリーテーブルを最終カウントで更新
2. エグゼクティブサマリーを追加：
   • 検出された問題の総数
   • すぐの対応が必要な致命的な問題
   • インパクト分析の結果
   • 修正の優先度推奨順
3. ステータスを「完了」に更新
4. ユーザーにレポート位置を通知

---

汎用レビューカテゴリ

これらのチェックは、ドメインに関わらず すべての変更されたコード に適用されます。

---

カテゴリ：セキュリティ基礎

ハードコードされたシークレット

diff をチェック：

• 変更されたコード内の API キー、パスワード、シークレット
• パターン：api_key、apiKey、password、secret、token、credential リテラル値付き

成功条件: diff にハードコードされたシークレットなし（環境変数を使用すべき） 重大度: 致命的

---

Eval と動的コード実行

diff をチェック：

• JavaScript/TypeScript：eval(、new Function(、setTimeout("、setInterval("
• Python：eval(、exec(、compile(

成功条件: 変更された行に動的コード実行なし 重大度: 致命的

---

コマンド インジェクション

diff をチェック：

• Python：subprocess と shell=True、os.system(
• Go：exec.Command( と未検証入力

成功条件: シェルコマンド内に検証されていないユーザー入力なし 重大度: 致命的

---

カテゴリ：コード品質

Console/Print ステートメント

diff をチェック：

• JavaScript/TypeScript：console.log、console.debug、console.info
• Python：print( ステートメント

成功条件: プロダクションコード変更内にデバッグステートメントなし 重大度: 低

---

TODO/FIXME コメント

diff をチェック：

• TODO:、FIXME:、HACK:、XXX: コメント

成功条件: 新しい TODO は issue で追跡すべき 重大度: 低

---

空の Catch/Except ブロック

diff をチェック：

• JavaScript/TypeScript：catch { } または catch(e) { }
• Python：except: pass または空の except ブロック

成功条件: すべてのエラーハンドラーでログまたは再スロー 重大度: 高

---

カテゴリ：LLM コードの匂い

プレースホルダー実装

diff をチェック：

• TODO、PLACEHOLDER、IMPLEMENT、NotImplemented
• return None、return []、return {} だけの関数

成功条件: プロダクションコードにプレースホルダー実装なし 重大度: 高

---

過度に汎用的な抽象化

diff をチェック：

• GenericHandler、BaseManager、AbstractFactory のような名前の新しいクラス/関数
• 明確な再利用の正当性のない抽象化

成功条件: 抽象化は実際の再利用によって正当化される 重大度: 低

---

カテゴリ：インパクト分析

破壊的な変更

diff が以下を変更するかチェック：

• エクスポートされた関数/クラス - 他の場所でのインポートを検索
• API エンドポイント - 呼び出し元を検索
• 共有型/インターフェース - 使用を検索
• 設定スキーマ - コンシューマーを検索

成功条件: すべての影響を受けるコードが特定され説明される 重大度: 高（考慮されていないインパクトが見つかった場合）

---

カテゴリ：簡潔化

重複ロジック

diff をチェック：

• 繰り返されるコードパターン（単なる構文的類似ではない）
• わずかな変更がある copy-paste コード
• 類似の検証、変換、またはフォーマット化ロジック

成功条件: 変更されたコード内に明らかな重複なし 重大度: 中 提案: 共有ロジックを再利用可能な関数に抽出

---

不要な複雑性

diff をチェック：

• 深くネストされた条件分岐（3 レベル以上）
• 複数の無関係なことをする関数
• 過度に複雑な制御フロー

成功条件: コードは合理的にフラットで焦点が絞られている 重大度: 中 提案: アーリーリターンを使用し、ヘルパー関数を抽出

---

冗長なパターン

diff をチェック：

• 言語内にもっと簡潔な代替案がるパターン
• 冗長な null チェックまたは型アサーション
• 不要な中間変数

成功条件: コードは言語のイディオマティックなパターンを使用する 重大度: 低 提案: 言語組み込みを使用して簡潔化

---

ドメイン固有のレビューアイテム

検出されたドメインに基づいて、適切なチェックリストを読んで適用します：

• フロントエンド検出（designer/）：frontend.md を読んでこれらのチェックを変更されたコードに適用
• バックエンド検出（server/、rag/、runtimes/）：backend.md を読んでこれらのチェックを変更されたコードに適用

---

最終サマリーテンプレート

## エグゼクティブサマリー

**レビュー完了**: {タイムスタンプ}
**検出事項の総数**: {数}

### 致命的な問題（必須修正）
1. {問題 1}
2. {問題 2}

### インパクト分析の結果
- {破壊的な変更または考慮されていないインパクトのサマリー}

### 高優先度（修正推奨）
1. {問題 1}
2. {問題 2}

### 推奨事項
{レビューされた変更に基づいた総合的な推奨事項}

---

エージェントへのノート

1. Diff にスコープ: 変更された行内の問題のみをフラグします。変更されていないコードはレビューしません。

2. 文脈を使用: 変更を理解するために完全なファイルを読みますが、フィードバックは diff のみをターゲットにします。

3. インパクトをチェック: 変更がエクスポート、API、または共有コードに触れる場合、影響を受けるコンシューマーを検索します。

4. 具体的に: すべての検出事項について、ファイルパス、行番号（diff から）、コードスニペットを含めます。

5. 優先順位付け: セキュリティの致命的な問題はすぐにフラグします。

6. ソリューションを提供: 各検出事項には修正方法の推奨事項を含めます。

7. 段階的に更新: 最後ではなく、各カテゴリの後にレビュードキュメントを更新します。