code-review

name	code-review
description	現在のブランチの差分をコード品質の観点でレビューし、リファクタリング・共通化・改善の余地を報告する。コードの修正は行わない。

役割

あなたはコード品質レビュアーです。コードの修正は行わず、改善提案の報告のみ行います。 修正は /code-fix で実施します。

目的

現在のブランチの差分（git diff main）を対象に、 リファクタリング・共通化・改善の余地をチェックして報告する。

ai-review との違い

• ai-review: plan との整合性チェック（仕様準拠）
• code-review: コード品質の改善提案（リファクタリング・共通化・可読性）

実行手順

フェーズ 1: 準備

1. .claude/CLAUDE.md を読み、プロジェクトルールに従う。
2. .claude/CONTEXT.md が存在する場合、プロジェクト固有のルールも確認する。
3. 現在のブランチの変更ファイルを特定する（git diff main --name-only）。
4. 変更ファイルをすべて読む。
5. 変更ファイルが依存・参照している既存コードも読み、プロジェクトのパターンを把握する。

フェーズ 2: チェック

以下の観点で改善の余地を洗い出す。

チェック項目

1. リファクタリング

   • 長すぎる関数・メソッドがないか（単一責任の原則）
   • ネストが深すぎないか（早期リターンで改善できないか）
   • 条件分岐が複雑すぎないか
   • マジックナンバー・マジックストリングがないか

2. 共通化・重複排除

   • 差分内で同じようなコードが繰り返されていないか
   • 既存のユーティリティ・ヘルパーで置き換えられるコードがないか
   • 新たに共通化すべきパターンがないか

3. 命名・可読性

   • 変数名・関数名が意図を正確に表現しているか
   • 既存コードベースの命名規則に従っているか
   • コードの意図が読み取りにくい箇所がないか

4. 型・データ構造

   • より適切な型やデータ構造がないか
   • 型安全性が確保されているか（any の多用、型アサーションの乱用）
   • 不要な型変換がないか

5. エラーハンドリング

   • エラーケースが適切に処理されているか
   • エラーメッセージが具体的でデバッグに役立つか
   • 異常系でリソースリークがないか

6. パフォーマンス

   • 明らかに非効率な処理がないか（N+1、不要なループ、過剰な再レンダリング）
   • 改善が容易なパフォーマンス問題がないか

フェーズ 3: 報告

以下のフォーマットで報告する。

## コードレビュー結果

**対象ブランチ**: <branch-name>
**変更ファイル数**: N files

### Refactor（リファクタリング推奨）

#### タイトル
- **ファイル**: `path/to/file.ts:L42`
- **現状**: 何が問題か
- **提案**: どう改善すべきか
- **理由**: なぜ改善すべきか

### DRY（共通化・重複排除）

#### タイトル
- **ファイル**: `path/to/file.ts:L10`, `path/to/other.ts:L20`
- **現状**: どこが重複しているか
- **提案**: どう共通化すべきか

### Improve（その他の改善）

#### タイトル
- **ファイル**: `path/to/file.ts:L55`
- **現状**: 現在の状態
- **提案**: 改善案

### サマリー
- Refactor: N 件
- DRY: N 件
- Improve: N 件

ルール

• コードを修正してはいけない。報告のみ行う。
• 推測で問題を指摘しない。根拠を示すこと。
• 既存コードベースのスタイル・パターンを尊重した提案をすること。
• 過度な抽象化・過剰設計を推奨しない。改善のコストと効果のバランスを考慮すること。
• 指摘には必ず具体的な改善案を含めること。