code-review

コードレビュー

形式的な応答ではなく、技術的な厳密さ、根拠に基づく主張、検証を重視した適切なコードレビュープラクティスを説明します。

概要

コードレビューには、次の3つの異なるプラクティスが必要です。

1. フィードバックを受ける - 形式的な同意ではなく、技術的な評価を行います
2. レビューを依頼する - code-reviewer サブエージェントを通じて体系的にレビューします
3. 検証ゲート - 完了を主張する前に証拠を確認します

それぞれのプラクティスには、参照ファイルで詳しく説明されている特定のトリガーとプロトコルがあります。

基本原則

社会的な心地よさより技術的な正しさを優先します。 実装前に検証します。思い込みで判断する前に質問します。主張する前に証拠を確認します。

このスキルを使うタイミング

フィードバックを受ける

次の場合に使います。

• 何らかの情報源からコードレビューのコメントを受け取ったとき
• フィードバックが不明瞭、または技術的に疑わしいとき
• 複数のレビュー項目の優先順位付けが必要なとき
• 外部レビュアーが十分なコンテキストを把握していないとき
• 提案が既存の決定と矛盾するとき

参照先： references/code-review-reception.md

レビューを依頼する

次の場合に使います。

• サブエージェント駆動開発でタスクを完了したとき（各タスクの後）
• 主要な機能やリファクタリングを完了したとき
• main ブランチにマージする前
• 行き詰まり、新たな視点が必要なとき
• 複雑なバグを修正した後

参照先： references/requesting-code-review.md

検証ゲート

次の場合に使います。

• テストの成功、ビルドの成功、または作業の完了を主張しようとしているとき
• コミット、プッシュ、または PR の作成前
• 次のタスクに移るとき
• 成功や完了を示唆する発言をするとき
• 作業に満足していると表明するとき

参照先： references/verification-before-completion.md

クイック判断ツリー

SITUATION?
│
├─ Received feedback
│  ├─ Unclear items? → STOP, ask for clarification first
│  ├─ From human partner? → Understand, then implement
│  └─ From external reviewer? → Verify technically before implementing
│
├─ Completed work
│  ├─ Major feature/task? → Request code-reviewer subagent review
│  └─ Before merge? → Request code-reviewer subagent review
│
└─ About to claim status
   ├─ Have fresh verification? → State claim WITH evidence
   └─ No fresh verification? → RUN verification command first

フィードバックを受けるプロトコル

応答パターン

READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT

主なルール

• ❌ 形式的な同意は禁止：「まったくそのとおりです！」「すばらしい指摘です！」「[何であれ]ありがとうございます」
• ❌ 検証前の実装は禁止
• ✅ 要件を言い換える、質問する、技術的な理由を示して反論する、またはそのまま作業を始めます
• ✅ 不明瞭な点がある場合：いったん止まり、不明瞭な項目すべてについて先に説明を求めます
• ✅ YAGNI の確認：提案された「適切な」機能を実装する前に、使用箇所を grep で調べます

情報源の扱い

• 人間のパートナー： 信頼します。内容を理解したうえで実装し、形式的な同意はしません
• 外部レビュアー： 技術的に正しいか検証し、問題が起きないか確認します。誤りがあれば反論します

プロトコル全文： references/code-review-reception.md

レビューを依頼するプロトコル

依頼するタイミング

• サブエージェント駆動開発で各タスクを完了した後
• 主要な機能を完了した後
• main にマージする前

手順

1. Git SHA を取得します：BASE_SHA=$(git rev-parse HEAD~1) および HEAD_SHA=$(git rev-parse HEAD)
2. 次の情報を指定して、Task ツール経由で code-reviewer サブエージェントを呼び出します：WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION
3. フィードバックに対応します：Critical はすぐに修正し、Important は先に進む前に修正し、Minor は後で対応するものとして記録します

プロトコル全文： references/requesting-code-review.md

検証ゲートのプロトコル

鉄則

最新の検証証拠なしに完了を主張してはいけません

ゲートの機能

コマンドを特定 → コマンドを最後まで実行 → 出力を読む → 主張が裏付けられていることを確認 → その後に主張

いずれかの手順を省略することは、検証ではなく嘘をつくことです

要件

• テストが成功：テスト出力で失敗が0件と示されている
• ビルドが成功：ビルドコマンドの終了コードが0
• バグが修正済み：元の症状を再現するテストが成功する
• 要件を満たしている：項目ごとのチェックリストで検証済み

危険信号 — STOP

「はずです」「おそらく」「〜のようです」と言う、検証前に満足を表明する、検証なしにコミットする、エージェントの報告を信頼する、検証を実行せずに成功を示唆する表現を使う

プロトコル全文： references/verification-before-completion.md

ワークフローとの連携

• サブエージェント駆動： 各タスクの後にレビューし、次に進む前に検証します
• プルリクエスト： テストの成功を検証し、マージ前に code-reviewer にレビューを依頼します
• 一般： 状況を主張する前に検証ゲートを適用し、無効なフィードバックには反論します

要点

1. 社交的な振る舞いより技術的な厳密さを重視します。迎合的な同意はしません
2. 体系的なレビュー手順を実施します。code-reviewer サブエージェントを使用します
3. 主張より証拠を優先します。必ず検証ゲートを設けます

検証します。疑問を持ちます。その後、実装します。証拠を示します。その後、主張します。