requesting-code-review

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

問題が連鎖する前に検出できるよう、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 サブエージェントをディスパッチします：

Task ツールを code-reviewer タイプで使用し、Code Reviewer Template のテンプレートに入力します。

必須のプレースホルダー：

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

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

重大度	対応
Critical	直ちに修正し、先に進まない
Important	次の主要タスクに進む前に修正する
Minor	後で対応する項目として記録し、先に進んでもよい

詳細は重大度のガイドラインを参照してください。

ワークフローとの統合

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

• 各タスクの後に必ずレビューする
• 問題が積み重なる前に検出する
• 次のタスクに進む前に修正する

計画の実行：

• 各バッチ（3 タスク）の後にレビューする
• フィードバックを得て、反映してから続行する

アドホック開発：

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

レビューへの異議申し立て

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

• 技術的な根拠を示して異議を申し立てる
• 動作を証明するコードやテストを提示する
• 計画の要件を参照する
• 説明を求める

異議申し立ての例を参照してください。

よくある間違い

決して行わないこと：

• 「簡単だから」という理由でレビューを省略する
• Critical の問題を無視する
• 未修正の Important の問題があるまま先に進む
• 技術的な根拠なく反論する

必ず行うこと：

• レビュー依頼に十分なコンテキストを含める
• Critical の問題を直ちに修正する
• 技術的な根拠を添えて意見の相違を記録する
• Critical の問題を修正した後に再レビューする

例

例が必要ですか？ レビューの例とワークフローでは、以下を確認できます。

• レビュー結果の完全な例
• 良いレビュー依頼と悪いレビュー依頼
• さまざまなシナリオにおけるレビューのワークフロー
• さまざまな重大度への対応方法
• 異議申し立てを行うタイミングと方法

テンプレートが必要ですか？ Code Reviewer Templateで、サブエージェントのディスパッチに使う完全なテンプレートを確認できます。