full-review

全体レビュー

モデルを選択する前に、ブランチを選択します。コーディネーターのみで行うレビューと決定論的なエビデンスの作業は、呼び出し権限の範囲内で進めます。割り当てられたレビュアーのコンテキストで、通常のレビューレンズを適用します。ワーカーをディスパッチする場合は、shared/references/model-preview.md と、そこで承認された唯一のルートスナップショットを使用します。ネストされたスキル、ランナー、再確認では、そのスナップショットを使用します。別のルートやワーカーを選択することはありません。

ワーカーをディスパッチする場合、モデル ID、対応する推論の強度、タスクのデフォルト値は、shared/model-routing.json からのみ取得します。ディスパッチ、再試行、再開の際は、保存されたルートを正確に維持してください。

焦点を絞った実装パスでは見つけられないリスクをレビューします。結果として、正確でエビデンスに裏付けられた判定を示します。次に結果を受け取るのは、作成者またはデリバリーワークフローです。スコープ、エビデンス、指摘事項、検証の限界、判定が明示された時点で、レビューは完了です。

レビュープラン

レビュープランはスコープの契約です。そこに定められていない範囲までカバーしたと主張してはいけません。レビュープランには scope、risk、seats、effort、verification が記載されています。デリバリーワークフローでは、ユーザーが承認したルーティングプランの JSON から導出します。その JSON が、シート、ランナー、モデル、推論の強度、モード、利用不可の場合のアクションを指定する、実行可能な唯一のソースです。

スコープ	使用するケース	最小限のレビュー構成
focused	ローカルなリスクを伴う、範囲の限られた変更	レビュー用シートを 1 つと、関連する決定論的チェック。
seam	統合タスク、共有コントラクト、または境界をまたぐ動作	ロジックと状態に対応し、根本原因を正確に特定できる承認済みのルート。プランで指定されている場合に限り、2 つ目のルートを追加します。
deep	明示的な深掘りの依頼、セキュリティ上重要な境界、移行、公開コントラクト、または残存リスクが高い場合	seam の構成に、選定したセキュリティ、データ、互換性、構造の専門家を加えたもの。

一律にレビュー担当者を招集してはいけません。シート名、モデルの選択、ランナー、推論の強度は、承認済みのプランとモデル一覧からのみ取得します。提示された、または引き継がれたレビューのモードとスコープを使用します。それらがない場合は、エビデンスで裏付けられる範囲で最も限定的かつ安全なスコープを使用します。選択によってスコープ、コスト、許可された副作用、または重大な未解決の判断が変わる場合に限り、質問してください。返答がないことは承認を意味しません。プランが承認されるまでは、外部ルートをディスパッチしないでください。深掘りレビューの直接の依頼が許可するのは深掘りスコープであり、未計画のルートディスパッチではありません。

一致するスナップショットなしでワーカーをディスパッチする場合、model-preview.md は task-shaped-model-routing.md、 model-roster.md、および host-model-execution.md を使用して、唯一の選択を決定します。一致するスナップショットがある場合は、変更せずに使用します。レビュープランには、決定されたルートを記載します。このスキルは、都合のよいランナーやコーディネーターのモデルに置き換えることはありません。

ワークフロー

1. 対象を確定します。プルリクエスト、コミット範囲、ローカルの差分、タスクファイル群、またはドキュメントです。差分が空であることも結果の一つであり、失敗ではありません。出力契約をこの時点で選択します。共有レビューのスナップショットが提供されている場合は、shared/references/reviewer-response.md の選択したセクション、またはブリーフに埋め込まれた同じセクションを使用します。単独のコードには references/review_output_schema.json を、単独のドキュメントには references/doc-findings-schema.json を使用します。そのスキーマだけを読み込みます。
2. すでにコンテキストにある有効なプロジェクト規約と、変更されたパスに関係するローカルの契約を確認します。差分、変更されたファイル、関連する周辺コード、既存のレビューコメントを収集します。既存のコメントは候補であり、事実ではありません。
3. コードをレビューする場合は、このスキルのディレクトリから scripts/review_scope.py を実行します。そのリスクシグナルを使って計画を確認または絞り込みます。ヘルパーが利用可能だからといって、対象を絞ったレビューの範囲を広げないでください。
4. 選択した懸念に該当する参照のみを読み込みます。references/bug_finders.md、references/panel_roles.md、references/conditional_specialists.md、または references/structural_quality_review.md です。要件ドキュメントの場合は、references/doc-personas/ の該当するペルソナのみを使用します。実際にワーカーへディスパッチする前にのみ references/review-dispatch.md を読みます。
5. 通常の懸念レンズは、割り当てられたレビュアーのコンテキスト内でのみ読み込みます。重大なリスクまたは未解決の疑問があり、承認済みスナップショットにそのルートが指定されている場合に限り、独立したスペシャリストをディスパッチします。ディスパッチする各担当者には、同じ範囲のコンテキスト、規約、出力契約を渡します。担当者の忠実性を保ちます。担当者を利用できない場合は、別の担当者で黙って代替せず、利用不可として記録します。ホストが対応している場合は、分離された永続サブエージェントまたはサポート対象のタスクコンテキストで、指定どおりのネイティブモデルと推論強度を使用します。ランナーは、外部または未対応のルートに限って使用します。各レビュアーのコンテキストは後の再確認に備えて保持し、実装者や他の独立レビュアーとは分離します。ホストが対応している場合は、独立した担当者を並行して実行します。最終的なコードレビューも、実装者から独立したものにします。
6. 実行可能な場合は、実行時の挙動、セキュリティ、正確性、互換性、信頼性、パフォーマンスに関する指摘を検証します。構造に関する指摘は変更されたコードを確認して裏付けます。検証できていない主張には未検証の印を付けるか、確信度を下げます。断定だけでブロッカーにしないでください。
7. コードの場合は references/filtering_pipeline.md を読みます。開始時に選択した出力契約を使用します。重複を排除し、場所が特定された証拠に裏付けられている指摘だけを残したうえで、有効な確信度のしきい値を適用します。確認済みの指摘はすべて確実に保持します。上限が適用されるのは、人間向けの要約のみです。量より精度を優先します。見た目上の好み、広範なリファクタリングの要望、対象範囲外の既存の問題は報告しないでください。
8. 判定を返します。既定では報告のみです。ユーザーまたは呼び出し元から修正が明示的に許可されている場合は、apply_fixes: true を記録し、その範囲内で修正を適用します。二度目の承認や、ユーザーによる特定の構文での指示は必要ありません。提出前に変更されたパスを確認します。

セキュリティとドキュメント

security_focus=true の場合は、記録されたセキュリティ上の決定に照らして実装を確認し、計画で指定されたセキュリティ担当者とデータ担当者のみを含めます。コメント数の上限に合わせるために、セキュリティ上の指摘を削除しないでください。

計画または要件ドキュメントの場合は、コード差分ではなく、実現可能性、範囲、一貫性、意思決定上の不足をレビューします。同じ範囲契約と証拠基準を維持します。

出力

呼び出し元から shared/references/review-evidence.md のスナップショットが提供された場合は、その共有契約に従って完全な最終 JSON レスポンスを作成します。ブリーフに埋め込みセクションが含まれている場合は、それらを使用してください。それ以外の場合は、shared/references/reviewer-response.md の「Introduction」、「Initial response」、「Evidence packet substitution」、「Completion」を読みます。ソースを再確認する場合は「Recheck」を、追補がある場合は「Prose correction」も追加します。「Batch endorsement」は、完全なレスポンスが必要となるバッチが宣言されている場合にのみ追加します。受け入れ契約が変更された場合も、完全なレスポンスが必要です。これらのセクションは、個別のスキーマとレポートテンプレートに置き換わります。人間向けレポートは、記録される JSON と分けてください。 対象を絞った再確認や文章の追補には、この契約の増分レスポンスプロトコルを使用します。拡張された記録では、すべてのスナップショットパスを扱い、以前の指摘 ID を保持し、取得済みのチェックおよびブラウザーの証拠を参照してください。CRITICAL、HIGH、MEDIUM、LOW は、それぞれ P0、P1、P2、P3 に対応付けます。確認済みの MEDIUM はすべて、証拠によって解決されるまで未解決の P2 に対応付けます。表示上の上限によって削除することはできません。コーディネーターは実際のレスポンスを記録し、検証ツールを実行します。実行の成功は承認を意味しません。

共有スナップショットのない単独のコードについては、人間向けレポートと、references/review_output_schema.json に準拠する JSON を返します。単独の要件文書については、代わりに references/doc-findings-schema.json を使用します。レポートに references/review_report_template.md を使用するのは、これらの単独モードのみです。

単独スキーマでは、新しいコードの指摘すべてに、安定した ID、ステータス（confirmed、unverified、または refuted）、重大度、確信度、カテゴリ、場所、証拠、最小限の有効な修正、および検証を含めます。再確認では ID と処置の根拠を保持します。文書に関する指摘には、そのセクションと引用した証拠を含めます。単独コードのレポートは、次の行で終えてください。

Bugs found: N | Verified: X | Refuted: Y | Verdict: APPROVE|COMMENT|REQUEST_CHANGES

別途作成する人間向けレポートには、選択したスコープ、予定されている担当者と不在の担当者、実施した検証、および網羅性の制限を記載します。単独モードの判定では、重大または高の指摘が残っている場合は REQUEST_CHANGES、意味のある中程度の指摘がある場合は COMMENT、それ以外は APPROVE を使用します。