| name | code-review |
| description | Reviews code changes for quality, conventions compliance, performance, and security. Triggers: review, check, validate, inspect, audit code quality. Source-code read-only — never modifies source code or test files. Outputs review report to output/reports/review/ (requires Write permission to output/reports/review/). Takes optional argument: /code-review <target-file or instruction>
|
| context | fork |
Code Review
プロジェクトのコード変更をレビューするスキル。
CLAUDE.mdの規約とdocs/development-patterns.mdのプロジェクト固有チェックリストに基づき、構造化されたフィードバックを返す。
前提条件
| 参照ファイル | 用途 | スタブ時のフォールバック |
|---|
docs/architecture.md | アーキテクチャパターン | project-config.md §4 を直接参照 |
docs/development-patterns.md | コード規約・アンチパターン | project-config.md §11 を直接参照 |
基本姿勢
- ソースコードは一切変更しない（読み取り専用）
- 指摘は具体的かつ対応可能なものに限る（「なんとなく気になる」は不可）
- 重要度を明示する（MUST / SHOULD / CONSIDER）
- 良い点も言及する（指摘だけにしない）
- 仕様書（タスクファイル）の要件を満たしているかを最優先で確認する
使い方
/code-review <対象ファイル or レビュー指示>
引数は省略可能。省略した場合はgit diffの変更範囲を対象とする。
ファイルパスを指定した場合はそのファイルの変更をレビューする。
例
/code-review 直近のコミットをレビューする
/code-review src/features/assignment/
/code-review output/tasks/TASK_auth.md
出力先
- デフォルト: 会話内でレポートを提示
- ファイル出力:
output/reports/review/REVIEW_<対象>.md（output/ディレクトリが存在する場合）
他スキルとの連携
| 前工程 | 本スキル | 後工程 |
|---|
/implementing-features /ui-ux-design /refactoring | /code-review | （最終工程） |
レビューワークフロー
- 変更範囲の把握 — 変更ファイル一覧を確認し、影響範囲を理解する
- 仕様との照合 — タスクファイルの受け入れ基準と実装を突き合わせる
- 観点別チェック — 下記のレビュー観点に沿って確認する
- レポート出力 — 下記のフォーマットで構造化されたフィードバックを返す
レビュー観点
1. 仕様準拠
- タスクファイルの受け入れ基準をすべて満たしているか
- 仕様にない機能が追加されていないか
- データモデル変更が仕様どおりか
2. コード品質・可読性
- 命名が意図を表しているか（変数、関数、コンポーネント）
- 関数の責務が単一か（1関数1責務）
- 不要なコード・コメントアウトが残っていないか
- 型定義が適切か（
anyの使用、不要なアサーション）
3. アーキテクチャ準拠
- プロジェクトのアーキテクチャパターン（
docs/architecture.md 参照）に沿っているか
- 状態管理の使い方が正しいか（docs/development-patterns.md参照）
- スキーマと型の一貫性
- パスエイリアスの使用
- 依存方向ルールに違反していないか（
CLAUDE.md「アーキテクチャガバナンス」参照）
4. パフォーマンス
- メモ化が適切に使われているか（過剰でも不足でもなく）
docs/development-patterns.md に記載されたパフォーマンス関連のアンチパターンがないか- 不要な再レンダリングが発生しないか
5. セキュリティ
- XSS: 安全でないHTML挿入がないか
- 入力値のサニタイゼーション/バリデーション
project-config.md セクション10のセキュリティポリシーに違反していないか
6. ダークモード対応
- 色指定がライト/ダーク両対応か
- ハードコードされた色値がないか
7. テスト
- 重要なロジックにユニットテストがあるか
- テストが仕様の振る舞いを検証しているか（実装詳細のテストではなく）
- テストの説明文が振る舞いを明記しているか
8. 後方互換性
- 既存データのマイグレーションが考慮されているか
- スキーマ変更がoptionalまたはデフォルト値付きか
- 既存のpublicインターフェースを破壊していないか
9. ドキュメント同期
- 実装変更に伴い
docs/ 配下が更新されているか
- ドキュメント未更新の場合は MUST 指摘として報告する
出力契約
セクション定義
| セクション | 必須 | 制約 |
|---|
| 概要 | ✅ | 変更ファイル数・影響範囲・仕様準拠・ドキュメント同期を必ず含む |
| 指摘事項 | ✅ | MUST→SHOULD→CONSIDER の順。各レベルが0件でも見出しは残す |
| 良い点 | ✅ | 最低1件。指摘だけのレビューにしない |
| 総合判定 | ✅ | 列挙値から1つ選択 |
重要度定義
| レベル | 判定基準 | 例 |
|---|
| MUST | CLAUDE.mdルール違反、既存テスト破壊、セキュリティ脆弱性、依存方向違反、docs/未更新 | アンチパターン使用、ハードコード色値、XSS |
| SHOULD | 可読性低下、パフォーマンス懸念、テスト不足、命名不適切 | メモ化欠如、any型使用、テストカバレッジ不足 |
| CONSIDER | 改善提案、代替アプローチ、コード整理 | 関数抽出の提案、型定義の整理 |
総合判定の列挙値
| 判定 | 条件 |
|---|
| 承認 | MUST指摘が0件 |
| 条件付き承認（MUST修正後） | MUST指摘が1件以上かつ修正可能 |
| 要修正 | アーキテクチャ変更や設計見直しが必要 |
指摘記述フォーマット
- [ ] `ファイルパス:行番号` 指摘内容。**理由**: 根拠。**修正案**: 具体的な修正方法。
- ファイルパスは
src/ からの相対パス
- 行番号は省略不可（範囲の場合は
L10-L15）
- MUST/SHOULDには修正案を必ず付記。CONSIDERは任意
語彙制約
| 用語 | 定義 |
|---|
| 仕様準拠 | タスクファイルの受け入れ基準をすべて満たしていること |
| ドキュメント同期 | 実装変更に対応する docs/ の更新が完了していること |
| 依存方向違反 | CLAUDE.md「アーキテクチャガバナンス」のルールへの抵触 |
レポートフォーマット
# コードレビュー: [変更の概要]
## 概要
- 変更ファイル数: X
- 影響範囲: [機能名]
- 仕様準拠: OK / NG
- ドキュメント同期: OK / NG
## 指摘事項
### MUST（必須修正）
- [ ] `ファイル:行` 指摘内容。**理由**: 根拠。**修正案**: 修正方法。
### SHOULD（推奨修正）
- [ ] `ファイル:行` 指摘内容。**理由**: 根拠。**修正案**: 修正方法。
### CONSIDER（検討）
- [ ] `ファイル:行` 指摘内容。**理由**: 根拠。
## 良い点
- [具体的に良かった点]
## 総合判定
- **承認** / **条件付き承認（MUST修正後）** / **要修正**
禁止事項
- ソースコードの変更（テストファイルも含む）
- 仕様書にない要件の追加要求
- 個人の好みに基づく指摘（プロジェクト規約に根拠がないもの）
- 重要度なしの曖昧な指摘
