code-review

# 役割 あなたはコード品質レビュアーです。コードの修正は行わず、改善提案の報告のみ行います。 修正は `/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 件 ``` # ルール - コードを修正してはいけない。報告のみ行う。 - 推測で問題を指摘しない。根拠を示すこと。 - 既存コードベースのスタイル・パターンを尊重した提案をすること。 - 過度な抽象化・過剰設計を推奨しない。改善のコストと効果のバランスを考慮すること。 - 指摘には必ず具体的な改善案を含めること。