code-review

コードレビューのスキル

差分に対して包括的なコードレビューを実施します。変更されたコードを分析し、セキュリティ上の脆弱性、アンチパターン、品質上の問題を特定してください。

入力モデル

このスキルでは、実行前にコンテキスト内に差分が提供されていることを想定しています。差分の生成は呼び出し元の責任です。

実行例：

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

コンテキスト内に差分がない場合は、ユーザーに差分の提供を依頼するか、差分の生成を提案してください（例：git diff、git diff main..HEAD）。

---

ドメインの検出

差分内のディレクトリパスに基づき、適用するチェックリストを自動検出します。

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

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

---

レビュープロセス

ステップ 1：差分を解析する

差分から以下を抽出します。

• 変更されたファイルの一覧
• 変更された行（追加および修正）
• ファイルパスに基づいて検出したドメイン

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

一時ファイルのパターンを使用してレビュードキュメントを作成します。

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 Report

**Date**: {current date}
**Reviewer**: Code Review Agent
**Source**: {e.g., "PR diff", "unstaged changes", "main..HEAD"}
**Files Changed**: {count}
**Domains Detected**: {list}
**Status**: In Progress

## Summary

| Category | Items Checked | Passed | Failed | Findings |
|----------|---------------|--------|--------|----------|
| Security | 0 | 0 | 0 | 0 |
| Code Quality | 0 | 0 | 0 | 0 |
| LLM Code Smells | 0 | 0 | 0 | 0 |
| Impact Analysis | 0 | 0 | 0 | 0 |
| Simplification | 0 | 0 | 0 | 0 |
{domain-specific categories added based on detected domains}

## Detailed Findings

{findings added here as review progresses}

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

各チェックリスト項目について、以下を実施します。

1. フィードバックの対象を差分の行のみに限定する - 変更されたコード内の問題のみを指摘します
2. ファイルのコンテキストを確認する - 周辺のコードを理解するため、ファイル全体を読みます
3. 関連するチェックを適用する - ドメインに適したチェックリスト項目を使用します
4. 指摘事項を記録する - 変更されたコード内で見つかった違反を記録します

重要な原則：レビュー対象は差分です。レビューを正確に行うために、ファイルの残りの部分をコンテキストとして参照します。

ステップ 4：影響分析

差分がコードベース内の他の部分に影響する可能性を確認します。

• 変更されたエクスポート／インターフェース - 他の箇所での使用を検索し、問題が起きないか確認します
• 変更された API シグネチャ - 呼び出し元を確認し、更新が必要かを調べます
• 変更された共有ユーティリティ - 影響を受ける可能性のある利用箇所を探します
• 設定／スキーマの変更 - 古い構造に依存するコードを特定します

考慮されていない影響は、リスクに応じた重大度を付けて指摘事項として報告します。

ステップ 5：各指摘事項を記録する

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

### [{CATEGORY}] {Item Name}

**Status**: FAIL
**Severity**: Critical | High | Medium | Low
**Scope**: Changed code | Impact analysis

#### Violation

- **File**: `path/to/file.ext`
- **Line(s)**: 42-48 (from diff)
- **Code**:

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

- **Issue**: {explanation of what's wrong}
- **Recommendation**: {how to fix it}

ステップ 6：レポートを仕上げる

すべてのチェックを完了したら、以下を行います。

1. 最終的な件数で概要テーブルを更新します
2. エグゼクティブサマリーを追加します。
   • 見つかった問題の総数
   • 直ちに対応が必要な重大な問題
   • 影響分析の結果
   • 修正の推奨優先順位
3. ステータスを「完了」に更新します
4. レポートの保存場所をユーザーに伝えます

---

汎用レビューカテゴリ

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

---

カテゴリ：セキュリティの基本

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

差分で確認する項目：

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

合格基準：差分内にハードコードされたシークレットがないこと（環境変数を使用する必要があります） 重大度：重大

---

Eval と動的コード実行

差分で確認する項目：

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

合格基準：変更された行に動的コード実行がないこと 重大度：重大

---

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

差分で確認する項目：

• Python：subprocess での shell=True、os.system(
• Go：サニタイズされていない入力を使った exec.Command(

合格基準：シェルコマンドに未検証のユーザー入力が使われていないこと 重大度：重大

---

カテゴリ：コード品質

コンソール/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 で確認するもの:

• 繰り返されるコードパターン（単なる構文的な類似性ではないもの）
• わずかな違いでコピー&ペーストされたコード
• 類似したバリデーション、変換、フォーマットのロジック

合格基準: 変更されたコードに明らかな重複がないこと 重大度: 中 提案: 共有ロジックを再利用可能な関数に抽出する

---

不必要な複雑さ

diff で確認するもの:

• 深くネストされた条件分岐（3 階層を超えるもの）
• 無関係な複数の処理を行う関数
• 過度に複雑な制御フロー

合格基準: コードが適度にフラットで焦点が絞られていること 重大度: 中 提案: 早期リターンを使用し、ヘルパー関数を抽出する

---

冗長なパターン

diff で確認するもの:

• 言語によりシンプルな代替手段があるパターン
• 冗長な null チェックや型アサーション
• 不必要な中間変数

合格基準: コードが慣用的なパターンを使用していること 重大度: 低 提案: 言語の組み込み機能を使用して簡素化する

---

ドメイン固有のレビュー項目

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

• フロントエンドを検出（designer/）: frontend.md を読み込み、変更されたコードにそれらのチェックを適用します
• バックエンドを検出（server/、rag/、runtimes/）: backend.md を読み込み、変更されたコードにそれらのチェックを適用します

---

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

## Executive Summary

**Review completed**: {timestamp}
**Total findings**: {count}

### Critical Issues (Must Fix)
1. {issue 1}
2. {issue 2}

### Impact Analysis Results
- {summary of any breaking changes or unaccounted impacts}

### High Priority (Should Fix)
1. {issue 1}
2. {issue 2}

### Recommendations
{Overall recommendations based on the changes reviewed}

---

エージェント向けの注意事項

1. diff に対象を限定: 変更された行の問題のみを指摘してください。変更されていないコードはレビューしないでください。

2. コンテキストを活用: 変更を理解するためにファイル全体を読み込みますが、フィードバックは diff のみを対象とします。

3. 影響を確認: 変更がエクスポート、API、共有コードに触れる場合は、影響を受ける利用側を検索してください。

4. 具体的に: すべての指摘にファイルパス、行番号（diff から）、コードスニペットを含めてください。

5. 優先順位付け: 重大なセキュリティ問題は直ちに指摘してください。

6. 解決策を提示: 各指摘には、修正方法の推奨事項を含めてください。

7. 段階的に更新: レビュー文書は最後ではなく、各カテゴリの後に更新してください。