review-diff

差分をレビューする

レビューは常にサブエージェントで実行します。実装担当者（おそらくあなたです）とは異なるモデルを使い、新しいコンテキストで実施します。 各サブエージェントは、確認対象と読むコードの範囲を指定したファイルである、1 つの 観点 からレビューします。 あなたは範囲、観点、起動、確認、振り分け、修正、報告を担当します。

ほかのスキルでも、独自の観点セットを使ってこの流れを再利用します（たとえば /deep-review）。

1. 範囲

デフォルトの変更セットは、作業ツリーと現在のブランチの HEAD との差分です。 git diff HEAD に加えて、差分には表示されない未追跡ファイル（git status --short）も含めます。 変更セットが空の場合（たとえば、フィーチャーブランチ上のクリーンなツリーの場合）は、 main とのマージベースなど、対象範囲をユーザーに尋ねます。 変更セットが空のままレビュー担当者を起動しないでください。

該当する場合は、観点を元の作業と照らして評価できるよう、起点となった課題、タスク、計画を探します。

2. 観点

呼び出し元のスキルが指定する観点セットを使います。指定がなければ、標準セットとして次の 2 つをどちらも strong ティアで使います。

• lenses/big-picture.md：アプローチ、適合性、境界、整合性、および起点となった作業。
• lenses/detail.md：ロジック、エッジケース、データフロー、細部の整合性。

レビュー担当者には絶対パスを伝えます。reviewer.md と標準の観点ファイルは、観点セットを指定するスキルにかかわらず、このスキル（review-diff）のディレクトリにあります。

3. モデルの選択

strong ティアの各観点について：

• ユーザーがモデルを指定した場合 → モデルごとにレビュー担当者を 1 人起動します。
• ユーザーが人数を指定した場合 → その人数分のレビュー担当者を起動します。
• どちらも指定されていない場合 → レビュー担当者を 1 人起動します。

ほかのティアの観点には、それぞれレビュー担当者を 1 人起動します。

/model-tiers スキルを使ってモデルを選びます。ユーザーが指定したモデルはその名前のまま使い、それ以外は観点のティアに応じて選びます。 レビュー担当者のモデルは /model-tiers のルールに従い、実装担当者とは異なるモデルにし、観点ごとに別のモデルを使います。

4. 起動

/model-tiers の説明に従って、すべてのレビュー担当者を並行して 1 つのメッセージで起動し、結果を待ちます。 各担当者には、次の内容を伝えます。

Read and follow <absolute path to review-diff's directory>/reviewer.md.
Lens: <absolute path to the lens file>
Review: <diff command, e.g. git diff HEAD, plus any untracked files by path>
Originating work: <issue/task/plan pointer, or "none">

ファイルの場所を示してください。説明に要約して含めないでください。

レビュー担当者が失敗した場合は、1 回だけ再試行します。再度失敗した場合は、ほかのレビュー担当者の指摘をもとに続行し、失敗したことを報告します。 すべてのレビュー担当者が失敗した場合は、進行を妨げる問題として報告し、停止します。

5. 確認と振り分け

すべてのレビュー担当者の指摘を統合します。複数の観点にわたって、根本原因が共通する指摘はまとめます。 特に設計に関する見解が異なる場合は、意見の相違を記録します。

対応または報告する前に、各指摘をコードと照らして確認します。 妥当でない指摘は除外し、その理由を報告に記載します。 fix-now または fix-trivial に分類された指摘を確認できない場合は、設計上の検討事項とします。 それ以外で確認できない指摘は除外します。

カテゴリ	対応
fix-now	直接修正します。
fix-trivial	修正が局所的で議論の余地がなければ、直接修正します。
design-question	修正せず、ユーザーが判断できるよう十分な背景を添えて提示します。
informational	簡潔に伝えます。ユーザーから依頼がない限り変更しません。

次の場合、fix-now を設計上の検討事項として扱います。

• 別のレビュー担当者が設計上の検討事項と判断した場合。
• 妥当な修正方法が複数ある場合。
• ユーザーから見える動作が変わる場合。

レビュー対象の差分の範囲を超える修正は、その差分によってバグが発生した場合を除き、見送ります。

6. 修正

fix-now と fix-trivial に該当する項目を修正します。既存のコードベースのスタイルに合わせます。プロジェクトのリンターが分かっている場合は実行します。

ユーザーから依頼がない限り、レビューを再実行しないでください。

7. レポート

1. レビュアー：レビュアーごとのレンズとモデル、および指摘件数。 cheap ティアのレビュアーは、レンズ、モデル、指摘の合計件数を1行にまとめてください。 フォールバックがあれば記載してください。別のティア、または実装者と同じモデルを使用したレビュアーなどです。
2. 修正済み：変更内容とその理由。些細な修正は簡潔にまとめてください。
3. 却下：チェックで却下された指摘を、理由とともに1行ずつ記載してください。
4. 設計上の論点：トレードオフと、意見が分かれた各レビュアーの見解を番号付きで記載してください。
5. 参考情報：特筆すべき点が残っていれば、1行で記載してください。

各指摘の出どころとなったレンズ名を記載してください。 修正が不要で、設計上の論点もない場合は、その旨を1文で記載してください。