requesting-code-review

コードレビューの依頼

クライアントが対応している場合は、コードレビュー用のサブエージェントまたは並列ワーカーを起動し、問題が連鎖する前に発見します。Claude Code では、pr-review-toolkit:code-reviewer を起動します。レビュー担当者には、セッション履歴全体ではなく、具体的なコンテキストを渡します。これにより、レビュー担当者は思考過程ではなく成果物に集中でき、自分のコンテキストをその後の作業に使えます。クライアントにワーカー機能がない場合は、新たにレビューを行う段階を設け、同じレビューを順番に実施します。

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

独立性のルール： マージ前に、コードを書いたプロバイダーとは別のモデルプロバイダーによる独立したレビューを受けます。レビュー担当者の作業量はリスクに応じて調整します。些細な変更では少なく、動作、セキュリティ、データ、広範囲に及ぶ変更では多くします。同じプロバイダーによるレビューでも、作業中の問題発見には役立ちますが、独立したレビューとは見なされません。

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

必須：

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

任意ですが、効果的です：

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

依頼方法

1. git SHA を取得します：

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

2. コードレビュー用サブエージェントを起動します：

クライアントのワーカー機能を使い、code-reviewer.md のテンプレートに記入します。Claude Code では、Task ツールを使って pr-review-toolkit:code-reviewer を起動します。

プレースホルダー：

• {WHAT_WAS_IMPLEMENTED} - 直前に実装した内容
• {PLAN_OR_REQUIREMENTS} - 実装が満たすべき内容
• {BASE_SHA} - 開始時のコミット
• {HEAD_SHA} - 終了時のコミット
• {DESCRIPTION} - 簡潔な概要

3. スナップショットを固定します：

base、head、変更されたパス、diff のダイジェストを記録します。レビュー担当者にも、それらを繰り返して確認するよう依頼します。異なるスナップショットを対象とした結果は破棄します。レビュー後にコードを変更した場合、以前の結果は新しい head を対象としていません。

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

• Critical な問題は直ちに修正します
• Important な問題は先に進む前に修正します
• Minor な問題は後で対応できるよう記録します
• レビュー担当者の指摘が誤りなら、理由を添えて異議を伝えます
• 修正後、新しいスナップショットに対して、同じレビュー担当者に修正内容を重点的に確認してもらいます

最初のレビューで問題が見つかった、または不正な形式の出力が返されたという理由で、レビュー担当者を変更してはいけません。変更できるのは、レビュー担当者のプロバイダーが利用できない場合に限ります。レビュー回数に上限はありません。正確な head に対して対応可能な欠陥が見つからなくなるまで続けます。

例

[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 a code-review worker from a different provider]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[Subagent 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 タスク）ごとにレビューします
• フィードバックを受けて反映し、続行します

アドホック開発：

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

危険信号

決してしてはいけないこと：

• 「簡単だから」という理由でレビューを省略する
• Critical な問題を無視する
• Important な問題を未修正のまま進める
• 妥当な技術的フィードバックに反論する

レビュー担当者の指摘が誤っている場合：

• 技術的な理由を添えて異議を伝えます
• 動作を証明するコードやテストを提示します
• 説明を求めます

テンプレートは次を参照してください：requesting-code-review/code-reviewer.md

参考ファイル

独立したレビュー担当者による変更完了の検証が必要な場合は、プロバイダー横断コードレビューを読んでください。