requesting-code-review

コードレビューの依頼

正規の code-reviewer.md テンプレートを使ってレビュアーサブエージェントを起動し、問題が連鎖する前に検出します。レビュアーに渡すのは、評価に必要な情報だけを正確にまとめたコンテキストです。セッションの履歴は渡しません。これにより、レビュアーは思考過程ではなく成果物に集中でき、自分のコンテキストもその後の作業のために保持できます。

このスキルは、method-pack の実装作業における正規のレビュー依頼ワークフローです。十分な証拠とコンテキストが揃い、レビュアーに評価を求める範囲の権限境界が明確になった後にのみ、レビューを依頼してください。

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

指摘事項を先に示す： レビューでは、要約より先に具体的な指摘事項を示します。まずバグ、リスク、テストを扱います。長所や全般的な評価も有用ですが、正しさ、証拠、アーキテクチャ、廃止に関する問題を覆い隠してはいけません。

レビューの準備が整ったことは、マージの承認を意味しません。レビューによって不確実性を減らし、準備状況を推奨できますが、verification-before-completion の代わりにはならず、完了の権限を与えるものでもありません。

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

必須：

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

任意ですが有用：

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

必須の出力

このワークフローを終える前に、次の事項を明確に説明できる必要があります。

1. レビュー対象となる正確な範囲
2. 成功の基準となる計画、要件、または契約
3. 許容される動作と対象外事項を定義する Product / Requirement Baseline
4. 想定されるアーキテクチャの状態を定義する Architecture / Runtime Boundary Baseline
5. すでに存在する新しい証拠
6. 維持すべき互換性の境界
7. 古い所有者、フォールバック、パッチのうち、維持、縮小、廃止するもの
8. レビュアーが具体的に検証すべき事項
9. レビュアーの役割が助言のみか、より上位のマージ推奨も含むか
10. Aegis Visibility：指摘事項を先に示す順序、証拠の十分性、ベースラインとの整合性、互換性、廃止リスクが、このレビュー依頼にとって重要な理由
11. 意味的コンテキストの範囲：レビューで維持すべき、関連する正規用語、非推奨の別名、公開上の命名境界

この method pack におけるレビューは、助言と証拠に基づくものです。それだけで完了を承認する権限はありません。

要件と成果を双方向に比較します。欠落や弱体化だけでなく、根拠のない追加や強化も確認します。許可された変換の範囲内で、関連する関係性、動作、所有権、限定条件を維持します。証拠のある不具合には、関連する有効なケースを添えます。新たな受け入れ基準を追加したり、許可された要約や修正を却下したり、網羅的な同等性を要求したりしてはいけません。

依頼方法

1. 最低限のレビュー情報を集めます：

• 実装した内容
• 満たすべき要件／計画／仕様／ADR
• 差分が準拠すべき基準文書／現行の正規文書。要件／プロダクトとの整合性と、アーキテクチャ／現行の正規文書との整合性を含みます
• すでにある根拠（テスト、コマンド、ログ、スクリーンショット、差分の概要）
• レビュアーの注意を要する互換性の境界またはリスク
• 廃止すべき旧経路、フォールバック、重複する担当箇所、一時的なパッチがあるかどうか
• 差分に、ADR Auto Backfill または基準同期での検出事項を必要とする、永続的なアーキテクチャ上の決定が含まれるかどうか
• ADR に関する対応または基準同期の完了が対象範囲に含まれる場合、recording-architecture-decisions を使用したか、または使用すべきかどうか
• 公開名／ドメイン名が対象範囲に含まれる場合は、関連する有効な CONTEXT.md の言語。受動的な読み取りでは、有効なモデリングは読み込まれません

これらに答えられない場合は、レビューを依頼する前に作業を止めて情報を集めてください。

2. Git のレビュー範囲を定義します：

# Before the coordinator's task commit
REVIEW_SCOPE=working-tree
BASE_SHA=$(git rev-parse HEAD)

# Or for already committed work
REVIEW_SCOPE=committed-range
BASE_SHA=<known-start>
HEAD_SHA=$(git rev-parse HEAD)

作業ツリーをレビューする場合は、タスクに属する未追跡パスを明示してください。レビュアーに見せるためだけにステージングしないでください。

3. レビュアーのサブエージェントに依頼します：

Task ツールを使って、汎用レビュアーのサブエージェントを起動します。requesting-code-review/code-reviewer.md にある標準テンプレートを埋めてください。別途指定したエージェントプロンプトに頼らないでください。

プレースホルダー：

• {WHAT_WAS_IMPLEMENTED} - 実装した内容
• {PLAN_OR_REQUIREMENTS} - 実装が満たすべき内容
• {EVIDENCE} - すでに得られている最新のテスト、コマンド、ログ、検証結果
• {COMPATIBILITY_BOUNDARY} - 破壊してはならない既存の動作やインターフェース
• {RETIREMENT_NOTES} - 旧担当箇所／フォールバック／パッチ／重複ブランチと、予定している処置
• {REVIEW_SCOPE} - working-tree または committed-range
• {BASE_SHA} - 開始時のコミット
• {HEAD_SHA} - 終了時のコミット、または WORKTREE
• {DESCRIPTION} - 簡単な概要

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

• Critical の問題は直ちに修正します
• Important の問題は先に進む前に修正します
• Minor の問題は後で対応できるよう記録します
• レビュアーが誤っている場合は、理由を示して異議を唱えます
• フィードバックで根拠の不足が明らかになった場合は、自信を根拠に議論するのではなく、不足している検証を実行します
• フィードバックで Design Defect / Implementation Drift、古いロジック、またはアーキテクチャドリフトなどのレガシーエイリアスが明らかになった場合は、今すぐ修正するか、基準を訂正するか、廃止条件を記録するかを明確に決定します

例

[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 reviewer subagent using requesting-code-review/code-reviewer.md]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/aegis/plans/deployment-plan.md
  EVIDENCE: pytest tests/index/test_verify.py -v -> 12 passed
  COMPATIBILITY_BOUNDARY: Existing index format and CLI flags must remain stable
  RETIREMENT_NOTES: Legacy repair fallback still exists in old helper; remove once new path covers all four issue types
  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 タスク）の後にレビューします
• フィードバックを受けて適用し、続行します

アドホックな開発：

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

レビュアーが確認すべきこと

レビュー依頼では、レビュアーに少なくとも次の点を確認するよう求めてください。

• 指摘を最初に提示：バグを優先、リスクを優先、テストを優先
• 根拠が十分であること
• ベースラインと現行の権威ある情報源の整合性
• 合意済みの問題、成功を示す証拠、対象外の事項に照らした要件とプロダクトの整合性
• オーナー、契約、信頼できる唯一の情報源、互換性、廃止の境界に照らしたアーキテクチャと現行の権威ある情報源の整合性
• scope: requirements | architecture | both を用いた Design Defect / Implementation Drift の分類
• 従来の用語との対応付け：baseline defect、architecture defect、architecture drift は、並行する別の結果用語として扱わず、Design Defect / Implementation Drift に対応付ける
• オーナー重複のリスク
• 互換性の境界
• 長期的に維持すべきアーキテクチャ上の決定について、ADR Auto Backfill またはベースライン同期の指摘が欠落していないこと
• ADR 対応またはベースライン同期の完了が対象範囲に含まれる場合、recording-architecture-decisions への引き継ぎが欠落していないこと
• 未検証の主張や、証拠の不足
• 廃止すべき、暫定的に維持すべき、または統合すべき古いロジック
• 公開名の不整合、非推奨用語の再混入、または establishing-project-context を組み合わせずにコードやドキュメントに記録された意味上の変更

レビューで「このコードは良いか」だけを尋ねるのでは、要件が不十分です。

危険信号

次のことは決して行わないでください。

• 「単純だから」という理由でレビューを省略する
• Critical な問題を無視する
• 修正されていない Important な問題をそのまま進める
• 妥当な技術的フィードバックに反論する
• レビュアーの承認を、権威ある完了と同等に扱う
• すでにある証拠を共有せずにレビューを依頼する
• 古い処理がどうなるかをレビュアーに伝えずに、新しいロジックを追加する

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

• 技術的な根拠を示して異議を唱える
• 正しく動作することを証明するコードやテストを提示する
• 説明を求める

レビューの境界

• レビューでは、マージ可能性、残存リスク、追加作業を提案できます
• レビューだけで、権威ある完了を認定することはできません
• レビューは不確実性を隠すのではなく、減らす必要があります

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