requesting-code-review

コードレビューを依頼する

問題が連鎖する前に発見できるよう、task ツールを使って code-reviewer サブエージェントを起動します。レビュー担当には評価に必要なコンテキストだけを正確に渡し、セッションの履歴は一切渡しません。これにより、レビュー担当が思考プロセスではなく成果物に集中でき、自分のコンテキストもその後の作業のために保てます。

基本原則： 早めに、頻繁にレビューします。

レビューを依頼するタイミング

必須：

• サブエージェント駆動型開発では、各タスクの完了後
• 大規模な機能の完了後
• main へのマージ前
• 変更がセキュリティ関連のコード（信頼できない入力、認証／認可、シークレット、インジェクションのシンク、サブプロセス／プラグインの境界、新しい依存関係）に触れる場合（security-reviewer を起動）

任意ですが、有用です：

• 行き詰まったとき（新たな視点を得るため）
• リファクタリングの前（ベースラインを確認するため）
• 複雑なバグの修正後

依頼方法

1. Git の SHA を取得します：

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. task ツールを使って、グローバルエージェントの code-reviewer、code-quality-reviewer、または security-reviewer を起動します：

code-reviewer、code-quality-reviewer、security-reviewer エージェントは、適切なレビューチェックリストとともにグローバルに登録されています。実装内容、プランの参照先、Git の差分範囲をコンテキストとして渡して起動します。エージェントは git diff {BASE_SHA}..{HEAD_SHA} を使って変更を調査します。

Task ツールのプロンプトに含めるコンテキスト：

• 直前に実装した内容（簡単な要約）
• 期待する動作（プランまたは要件の参照先）
• 開始コミット SHA（BASE_SHA）
• 終了コミット SHA（HEAD_SHA）

3. フィードバックに対応します：

• Critical の問題は直ちに修正します
• Important の問題は次に進む前に修正します
• Minor の問題は後で対応できるよう記録します
• レビュー担当の指摘が誤っている場合は、理由を添えて反論します

例

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[Dispatch code-reviewer sub-agent using the `task` tool]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[Sub-agent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

ワークフローとの連携

サブエージェント駆動型開発：

• 各タスクの後にレビューします
• 問題が積み重なる前に発見します
• 次のタスクに進む前に修正します

プランの実行：

• まとまりごと（3 タスク）にレビューします
• フィードバックを受けて反映し、続行します

アドホックな開発：

• マージ前にレビューします
• 行き詰まったときにレビューします

レビュー担当の選び方

エージェント	使用するタイミング	対応しないこと
spec-reviewer	実装の直後 — コードは仕様に一致しているか、それ以上でもそれ以下でもないか？	スタイルや品質についてのコメント
code-quality-reviewer	仕様への準拠を確認した後 — 分解、命名、エラー処理、テスト品質	スコープの再検討
security-reviewer	変更が信頼できない入力、認証／認可、シークレット、インジェクションのシンク、サブプロセス／プラグインの境界、新しい依存関係に触れる場合 — 仕様と品質の確認後	入力から影響までの経路を追跡せずに指摘を報告すること
code-reviewer	機能の完了時またはマージ前 — 変更全体の本番運用への準備状況	—
reviewing-interface-quality（スキル）	変更にユーザー向け UI が含まれる場合	—

実行順序が重要です。 まず仕様準拠を確認し、次にコード品質、その後にセキュリティ、最後に本番運用への準備状況をレビューします。仕様準拠の確認前に品質レビューを行うと、依頼された内容と異なるかもしれないコードを磨くことになり、仕様準拠の確認前にセキュリティレビューを行うと、意図的に誤っている可能性のある動作を監査することになります。subagent-driven-development を参照してください。

ディスパッチプロンプトの作成

レビュアーにはコンテキストがまったくありません。あなたが書く内容が、レビュアーの知るすべてです。あなたのセッション履歴は共有されません。曖昧なプロンプトを与えられたレビュアーからは、曖昧な指摘しか返ってきません。

プロンプトには、次の内容をこの順序で含めます。

1. 何を作成したか — 2 文で記述します
2. どう動作すべきか — 要件または計画タスクの本文を、ファイル参照ではなく全文貼り付けます
3. 差分の範囲 — BASE_SHA と HEAD_SHA
4. 確認してほしい箇所 — 変更したファイル
5. すでに把握していること — 行った変更とその理由
6. 返してほしい内容 — レポートの形式

要件の本文を貼り付けてください。 レビュアーに docs/plans/x.md を読むよう伝えると、ツール呼び出しが 1 回増え、別のタスクを読んでしまうリスクもあります。必要な本文はすでに手元にあります。

自分の考えを伝えないでください。 「エラー処理はしっかりしていると思います」と書くと、レビューが同意に傾きます。事実を示し、指摘を求めてください。

Review the implementation of Task 2 from the auth plan.

REQUIREMENT (verbatim from the plan):
  Add verifyIndex() and repairIndex() to src/index/verify.ts. verifyIndex()
  returns a list of issues across 4 types: orphaned, stale, duplicate,
  missing. repairIndex() fixes each type. Report progress every 100 items.

DIFF: git diff a7981ec..3df7661
FILES: src/index/verify.ts, src/index/types.ts, tests/index/verify.test.ts

KNOWN DEVIATION: used a WeakMap rather than the Map the plan specified,
so entries are collected with their request objects. Behavior identical.

Return: PASS or FAIL with file:line references for each finding.

フィードバックへの対応

必須のサブスキル： 提案を実装する前に receiving-code-review を使用してください。レビュアーが間違っていることもあります。誤った提案を何も考えずに実装するのは、レビューを受けないよりも悪い結果になります。

重大度	対応
Critical	ほかのことをする前に修正します
Important	次のタスクに取りかかる前に修正します
Minor	記録し、低コストで済むなら修正します。そうでなければ後回しにします

その後、再レビューを行います。 問題を見つけたレビュアーは、修正を承認したわけではありません。変更した内容を添えて、同じコンテキストで再度ディスパッチしてください。再レビューを省くと、「修正済み」の問題がそのままマージされてしまいます。

注意すべき兆候

次のことは絶対にしないでください。

• 「簡単だから」という理由でレビューを省略する
• Critical の問題を無視する
• Important の問題を未修正のまま進める
• 技術的に妥当なフィードバックに反論する
• タスクの本文を貼り付けず、レビュアーに計画ファイルを読ませる
• プロンプトに自分の評価を含める（レビューに偏りを生じさせます）
• 再レビューなしで修正を完了扱いにする
• 未コミットの作業をレビューする — まずコミットし、差分の範囲を明確にします

レビュアーが間違っている場合：

• 技術的な根拠を示して反論します
• 動作することを証明するコードやテストを提示します
• 詳細な説明を求めます

よくある間違い

セッションのコンテキストを付けてディスパッチする。 レビュアーがあなたの思い込みを引き継ぎ、コードではなくあなたの考え方をレビューしてしまいます。

差分の範囲を指定しない。 レビュアーがファイル全体を読み、今回の変更に含まれない既存コードについてコメントします。

コミット前にレビューする。 安定した差分の範囲がなく、レビュアーに保存途中の状態が見える可能性があります。

仕様と品質の両方を 1 人のレビュアーに任せる。 これらは別の問いです。まとめてしまうと、スコープに関する確認が必要なだけ行われなくなります。

レビューを形式的なものとして扱う。 すべてのレビューで「承認、問題なし」と返ってくるなら、プロンプトがレビューに偏りを生じさせているか、適切なレビュアーを使っていない可能性があります。