code-review

コードレビュー

概要

当初の計画、コーディング規約、学習済みのプロジェクトパターンに照らした包括的なコードレビューです。このスキルでは、徹底的な分析のために専任のコードレビュアーエージェントに処理を依頼し、すべての変更が根拠に基づき、計画に沿っており、規約を踏まえたうえでメインブランチに取り込まれるようにします。

開始時に伝えること： 「実装をレビューするため、コードレビュースキルを使用します。」

---

フェーズ 1：コンテキストの収集

目標： 何が変更されたのか、計画で何が求められていたのか、どの規約が適用されるのかを特定します。

アクション

1. レビュー対象の変更を取得します：

git diff HEAD~N..HEAD          # or specific commit range
git log --oneline HEAD~N..HEAD # what was done

2. 計画ドキュメントを探します：

ls docs/plans/*.md | tail -1

3. memory/learned-patterns.md からプロジェクトの規約を読み込みます

4. 以下を特定します：

   • 変更されたファイル
   • 計画／仕様で求められていた内容
   • 適用される規約

停止 — 以下を満たすまでフェーズ 2 に進まないでください：

• 変更されたファイルをすべて特定している
• 計画または仕様の要件を読み込んでいる
• メモリから関連する規約を読み込んでいる
• 構築すべきものを説明できる

---

フェーズ 2：コードレビュアーへの依頼

目標： 構造化されたレビュー依頼を code-reviewer エージェントに送ります。

レビュープロンプトのテンプレート

Review the following changes against:
1. Plan: [plan document or requirements]
2. Conventions: [learned patterns from memory]
3. Standards: [CLAUDE.md rules]

Changes:
[git diff output or file list]

Check for:
- Plan alignment (did we build what was specified?)
- Code quality (DRY, YAGNI, naming, structure)
- Error handling (edge cases, failure modes)
- Security (injection, XSS, auth issues)
- Test coverage (are changes tested?)
- Performance (obvious bottlenecks)
- Documentation (are public APIs documented?)

停止 — 以下を満たすまでフェーズ 3 に進まないでください：

• レビュー依頼を送信している
• レビュアーエージェントから指摘が返されている

---

フェーズ 3：問題の分類と解決

目標： 指摘を分類し、すべての重大な問題を修正します。

問題の分類表

カテゴリ	定義	必要な対応
重大	バグ、セキュリティ上の問題、データ損失のリスク、計画違反	マージ前に必ず修正する
重要	コード品質、テスト不足、規約違反	マージ前に修正することが望ましい
提案	スタイル、命名、軽微な改善	可能であれば対応し、時間があれば修正する

修正ループ

重大および重要な問題について：

1. 問題を修正します
2. テストを実行して修正を検証します
3. 該当する修正について、コードレビュアーエージェントに再度依頼します
4. 重大な問題がなくなるまで繰り返します

停止 — 以下を満たすまでフェーズ 4 に進まないでください：

• 重大な問題をすべて解決している
• 重要な問題をすべて解決するか、理由を明記して保留にしている
• すべての修正後にテストスイートがパスしている

---

フェーズ 4：自己学習への反映

目標： レビュー中に見つかったパターンを今後のセッションに活用できるよう保存します。

アクション

1. 新しいパターンを特定した場合は、memory/learned-patterns.md を更新します
2. よくあるミスが見つかった場合は、今後の参考として記録します
3. 計画の調整が必要だった場合は、memory/decisions-log.md を更新します

---

レビュー出力形式

## Code Review Summary

**Scope:** [files/components reviewed]
**Plan alignment:** [aligned / minor deviations / major deviations]

### Critical Issues (N)
1. **[Issue title]** — `file:line`
   Problem: [description]
   Fix: [specific recommendation]

### Important Issues (N)
1. **[Issue title]** — `file:line`
   Problem: [description]
   Fix: [specific recommendation]

### Suggestions (N)
1. **[Suggestion]** — `file:line`

### What Was Done Well
- [Positive observations]

---

判断表：レビューの深さ

変更の種類	レビューの深さ	レビュアー
新機能（100 行超）	詳細レビュー：計画との整合性＋品質＋セキュリティ＋テスト	code-reviewer agent
バグ修正（50 行未満）	集中的なレビュー：回帰テスト＋根本原因＋修正の妥当性	code-reviewer agent
リファクタリング（動作変更なし）	動作の維持：すべてのテストがパスし、回帰がないこと	code-reviewer agent
設定／インフラの変更	セキュリティ＋正確性：シークレットが露出せず、構文が正しいこと	code-reviewer agent
ドキュメントのみ	正確性＋完全性：現在のコードの動作と一致していること	インラインレビュー

アンチパターン／よくある間違い

アンチパターン	それが間違っている理由	正しいアプローチ
「小さな修正」のレビューを省略する	小さな変更でも本番環境の停止につながります	すべてをレビューします
計画を確認せずにレビューする	要件がなければ正しさを検証できません	必ず最初に計画を読み込みます
テストを再実行せずに問題を修正する	修正によって新たなバグが発生する可能性があります	修正のたびにテストスイート全体を実行します
一般的なフィードバック（「問題なさそうです」）	具体的な対応につながらず、実際の問題を見逃します	修正案とともに具体的なコード行を指摘します
自分のコードだけをレビューする	作成者の盲点によって欠陥を見逃します	必ずコードレビュアーエージェントを呼び出します
重大な問題への対応を先送りする	重大な問題は本番環境でのインシデントにつながります	マージ前に必ず修正します。例外はありません

---

正当化 — こう考えたら作業を中止してください

言い訳	実態
「単なるタイプミスの修正です」	タイプミスの修正でも API を壊す可能性があります。レビューしてください。
「このコードには自信があります」	自信があることと、正しいことは同じではありません。レビューしてください。
「テストは通っています」	テストでバグを見逃すことがあります。レビューしてください。
「単なるスタイル／書式の変更です」	スタイルの変更でもバグが発生する可能性があります。レビューしてください。
「誰も気づきません」	まさにそのときにバグがリリースされます。レビューしてください。
「あとでレビューします」	「あとで」は決して訪れません。今すぐレビューしてください。
「締め切りが迫っています」	バグをリリースするほうが、レビューするよりも大きなコストがかかります。レビューしてください。

---

サブエージェントを呼び出せるケース

タスクのパターン	呼び出し先	タイミング
複数の独立したファイル／モジュールのレビュー	Agent ツールで subagent_type="Explore" を指定	レビューの対象範囲が複数の無関係なモジュールにまたがる場合
セキュリティに重点を置いたレビュー	Agent ツールで security-review スキルを呼び出す	変更が認証、入力処理、または外部 API に関わる場合
パフォーマンスへの影響評価	Agent ツールで performance-optimization スキルを呼び出す	変更がホットパスまたは大量のデータを扱う処理に影響する場合

呼び出し時は dispatching-parallel-agents スキルの手順に従ってください。

---

統合ポイント

スキル	関係
planning	レビューで、実装が承認済みの計画に沿っているか確認します
test-driven-development	レビューで、テストカバレッジと TDD の遵守状況を確認します
verification-before-completion	検証を行う前提条件としてレビューが必要です
self-learning	レビューで得た知見を学習したパターンに反映します
acceptance-testing	すべての受け入れ基準に対する受け入れテストが存在するか確認します
systematic-debugging	レビューでバグが見つかった場合は、デバッグスキルに切り替えます
security-review	レビュー中に見つかったセキュリティ上の問題をきっかけに、より詳細なセキュリティ分析を行います

---

鉄則

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: NO MERGE WITHOUT REVIEW                            │
│                                                                 │
│  Every change gets reviewed. No exceptions for "small fixes"   │
│  or "obvious changes." If you are about to merge without       │
│  review, STOP immediately.                                     │
└─────────────────────────────────────────────────────────────────┘

---

スキルの種類

RIGID — 4 段階のプロセスは必須です。すべての変更をコードレビュアーエージェントがレビューする必要があります。レビューなしでマージしてはいけません。例外はありません。