Smart review

Smart Review

ローカルブランチの変更をデフォルトブランチと比較し、コードレビューを実施する。

オプション

• -p <プロンプト>: レビュー観点の追加指示（例: -p セキュリティを重点的に）
• -o <path>: レビュー結果をファイルに出力（例: -o reviews/review.md）

ツール選択

GitHub API 操作には GitHub MCP ツールを優先。git 操作は Bash。

手順

1. 状態確認

以下を並列実行:

Bash: 現在のブランチ名、デフォルトブランチの特定（git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'、失敗時は develop → main → master の順で探索）、git log --oneline <default-branch>..HEAD、git diff <default-branch>...HEAD --stat、git status --short

• デフォルトブランチと差分なし → 「レビュー対象の変更がありません」で終了
• 未コミット変更あり → ユーザーに通知（コミット済みの変更のみレビュー対象）

2. Issue 読み取り（該当時）

引数に Issue 番号がある場合、またはブランチ名から Issue 番号を抽出できる場合:

• issue_read で Issue を取得し、タイトル・本文・受け入れ基準のみ保持する（コメント履歴・メタデータ等はコンテキストに残さない）
• レビュー基準に「要件適合」を追加

Issue 番号がない場合は一般的なコードレビュー観点のみでレビュー。

3. 変更内容の分析

git diff <default-branch>...HEAD で全変更を取得する。

差分が大きい場合（20ファイル超）の戦略:

1. --stat の出力からファイルを以下の優先度で分類:
   • 高: ビジネスロジック、API エンドポイント、認証・認可、データベース操作、セキュリティ関連
   • 中: ユーティリティ、設定ファイル、型定義
   • 低: テスト、ドキュメント、スタイル、自動生成ファイル
2. 高→中の順に Read で詳細確認。低優先度は stat の変更量が異常でない限りスキップ可
3. 全ファイルを均等に見るより、高リスク箇所を深く見る方が価値がある

コンテキストの読み取り: 差分行だけでなく、変更の影響を正しく判断するために必要な周辺情報も確認する:

• 変更された関数の呼び出し元（Grep で検索）
• 変更されたインターフェース・型の利用箇所
• 関連するテストファイルの有無と内容

4. レビュー実施

コンテキスト圧縮により Step 3 の diff 内容が失われている場合は、git diff <default-branch>...HEAD を再実行して取得する。

以下の観点でレビューする。指摘はすべて「本番で問題を引き起こすか」を基準にフィルタする — コードが正しく動作し、保守性にも実質的な影響がないなら指摘しない。

必須観点:

• バグリスク: エッジケース、null/undefined、off-by-one、競合状態、型の不整合
• セキュリティ: インジェクション、認証・認可、機密情報の露出、入力バリデーション
• コード品質: 可読性、命名、重複、複雑度（ただし動作に影響する問題のみ 🔴、好みレベルは指摘しない）
• テスト: 変更に対応するテストの有無。新しいロジックやバグ修正にテストがなければ指摘する

Issue がある場合の追加観点:

• 要件適合: Issue の要件・受け入れ基準を満たしているか
• スコープ: Issue の範囲外の変更が含まれていないか

-p の追加観点: ユーザー指示に応じた観点を追加

重要度の判定基準:

• 🔴 要修正: 本番でバグ・セキュリティ問題・データ損失を引き起こす可能性がある。または要件を満たしていない
• 🟡 提案: 改善すれば保守性・パフォーマンス・堅牢性が向上するが、現状でも動作はする
• 🟢 良い点: 意図的な良い設計判断を認める（1〜3個に絞る）

5. レビュー結果の出力

assets/review-format.md の形式で会話内に出力する。-o オプションがある場合は同じ内容をファイルにも出力。

6. 次のアクション提案

指摘事項がある場合:

• 「修正後に /smart-commit でコミットしてください」
• 要修正が多い場合は /smart-review-apply の使用を提案

指摘事項がない場合:

• 「問題ありません。/smart-pr で PR を作成できます」

注意事項

• レビューは日本語で記述する
• 変更していないコードへの指摘はしない（差分のみが対象）
• 指摘は具体的に — ファイル名と行番号を含める
• 主観的なスタイル指摘は避け、実質的な問題に集中する
• CLAUDE.md/rules にコーディング規約がある場合はそれも基準に含める
• 指摘数の目安: 🔴 は見つかった分すべて報告。🟡 は最大 5 件に絞り、影響度順に並べる。些末な指摘を大量に並べるとノイズになり、重要な問題が埋もれる