code-review

コードレビュー

パフォーマンス目的の対応ではなく、技術的な厳密さ、根拠に基づく主張、検証を重視する適切なコードレビューの実践方法を説明します。

概要

コードレビューには、次の3つの異なる実践が必要です。

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

それぞれの実践には、参照ファイルで詳しく説明しているトリガーと手順があります。

基本原則

常に YAGNI、KISS、DRY の原則を守ります。 正直に、忌憚なく、要点を率直に伝え、簡潔にします。

社会的な配慮より、技術的な正しさを優先します。 実装する前に検証します。決めつけずに質問します。主張する前に根拠を確認します。

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

フィードバックを受ける

次の場合に使用します。

• どのような相手からでもコードレビューのコメントを受け取ったとき
• フィードバックが不明瞭、または技術的に疑わしいと感じたとき
• 複数のレビュー項目に優先順位を付ける必要があるとき
• 外部のレビュアーに十分なコンテキストがないとき
• 提案が既存の決定と相反するとき

参照： 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

フィードバックを受ける手順

対応パターン

読む → 理解する → 検証する → 評価する → 応答する → 実装する

主なルール

• ❌ パフォーマンス目的の同意をしない：「まったくそのとおりです！」「すばらしい指摘です！」「[何に対しても]ありがとうございます」
• ❌ 検証する前に実装しない
• ✅ 要件を言い換えて確認する、質問する、技術的な理由を示して反論する、またはそのまま作業を始める
• ✅ 不明瞭な点がある場合：いったん止まり、不明瞭な項目をすべて確認する
• ✅ 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 ツールを使って、WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION を指定し、code-reviewer サブエージェントに処理を依頼します
3. フィードバックに対応します：Critical は直ちに修正し、Important は先に進む前に修正し、Minor は後で対応できるよう記録します

手順の全容： references/requesting-code-review.md

検証ゲートの手順

絶対原則

最新の検証結果がなければ、完了を主張してはいけません

ゲートの機能

コマンドを特定 → コマンドを完全に実行 → 出力を読む → 主張が裏付けられていることを検証 → その後で主張する

手順を1つでも省けば、検証ではなく嘘になります

要件

• テスト合格：テスト出力で失敗が0件であることを確認します
• ビルド成功：ビルドコマンドの終了コードが 0 であることを確認します
• バグ修正：元の症状を確認するテストが合格することを確認します
• 要件充足：行ごとのチェックリストで確認します

危険信号 - STOP

「はず」「おそらく」「～のようです」といった表現、検証前に満足を表明すること、検証せずにコミットすること、エージェントの報告を鵜呑みにすること、検証を実行せずに成功を示唆するあらゆる表現

手順の全容： references/verification-before-completion.md

ワークフローとの統合

• サブエージェント駆動： 各タスクの後にレビューし、次に進む前に検証します
• プルリクエスト： テストが通ることを確認し、マージ前にコードレビュアーによるレビューを依頼します
• 全般： ステータスを主張する前に必ず検証ゲートを適用し、妥当でないフィードバックには反論します

要点

1. 社交的な振る舞いより技術的な厳密さを優先します。形だけの同意はしません
2. 体系的なレビュープロセスを適用します。コードレビュアーのサブエージェントを使用します
3. 主張の前に証拠を示します。常に検証ゲートを適用します

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