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

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

応答パターン

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

主なルール

• ❌ 見せかけの同意は禁止：「おっしゃるとおりです！」「素晴らしい指摘です！」「[どんな内容であれ]ありがとうございます」
• ❌ 検証前の実装は禁止
• ✅ 要件を言い換える、質問する、技術的な理由を示して異議を唱える、またはそのまま作業を開始する
• ✅ 不明瞭な点がある場合：いったん停止し、不明瞭な項目すべてについて、まず確認を求める
• ✅ 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
• バグ修正：元の症状を再現するテストが成功する
• 要件充足：行ごとのチェックリストで確認済み

検証コマンド

# Tests (prefer bun)
bun test  # or: npm test

# Build
bun run build  # or: npm run build

# Lint
bun run lint  # or: npm run lint

# Type check
bun run typecheck  # or: bunx tsc --noEmit

危険信号 - 停止

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

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

ワークフローとの統合

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

要点

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

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