# Smart Review

> ローカル変更をデフォルトブランチと比較してセルフレビューする。Issue 番号があれば要件適合もチェックする。ユーザーが「レビューして」「変更確認して」「/smart-review」「/smart-review

- Skill: `mjcreativelab/smart-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mjcreativelab/smart-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mjcreativelab/smart-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mjcreativelab (https://skillmd.com/u/mjcreativelab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mjcreativelab/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](assets/review-format.md) の形式で会話内に出力する。`-o` オプションがある場合は同じ内容をファイルにも出力。

### 6. 次のアクション提案

指摘事項がある場合:
- 「修正後に `/smart-commit` でコミットしてください」
- 要修正が多い場合は `/smart-review-apply` の使用を提案

指摘事項がない場合:
- 「問題ありません。`/smart-pr` で PR を作成できます」

## 注意事項

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