review

レビュー

まずチェックポイントのトランスクリプトを読んで各変更の意図を把握し、その後、実際の差分を監査して問題を確認することで、現在のブランチのコード変更をレビューします。 これにより、開発者の意図と実際のコードの動作との不一致を検出できる、意図を踏まえたレビューを行えます。

応答形式

このスキルの呼び出しに対する最初の応答は、次の行から始めてください。

Entire Review:

その後に空行を1行入れ、続けて本文を記載します。

• この見出しを付けるのは、呼び出しに対する最初の応答のみです。同じ呼び出し内の後続ターンでは再掲しないでください。
• エラーや早期終了の応答（例：「git リポジトリではありません」、「ブランチとベースの間にコミットが見つかりません」）には見出しを含めないでください。

ルール

1. これは読み取り専用の監査です。レビュー中にファイルを変更しないでください。
2. 指摘事項を示す前に、必ずスコープバナーを表示し、レビュー対象をユーザーに知らせてください。
3. チェックポイントのコンテキストを利用できない場合でも、差分とコミットメッセージのみを使ってレビューを実施してください。レビューに意図のコンテキストが含まれていないことを明記してください。
4. 指摘事項はファイルごとにまとめ、各ファイル内では重大度の高い順（Critical > High > Medium > Low）に並べてください。
5. すべての指摘事項に、具体的な提案または説明を含めてください。問題を指摘するだけにしないでください。
6. 指摘事項を提示した後、修正計画が必要かユーザーに尋ねてください。自動修正は行わないでください。
7. ユーザーから明示的な依頼がない限り、生成ファイル、ロックファイル、バイナリファイルはレビューしないでください。

手順

1. 環境の確認

entire version を実行して CLI が利用可能か確認してください。インストールされていない場合は、チェックポイントの意図のコンテキストなしでレビューを進める（縮退モード）ことを明記してください。

2. ベース参照の検出

差分を取る対象となるメインラインブランチを特定してください。次の参照を順に試し、最初に存在するものを使用します。

git rev-parse --verify origin/HEAD 2>/dev/null
git rev-parse --verify origin/main 2>/dev/null
git rev-parse --verify origin/master 2>/dev/null
git rev-parse --verify main 2>/dev/null
git rev-parse --verify master 2>/dev/null

どれも存在しない場合は、ベース参照が見つからなかったことを伝え、指定を求めてください。

3. スコープの算出

git rev-list --count <base>..HEAD
git diff --stat <base>..HEAD

コミット数と変更ファイル数を記録します。これをスコープバナーに使用します。

4. チェックポイントの意図の収集（縮退モードでは省略）

git log --format='%H%x00%s%x00%b' <base>..HEAD

コミット本文から Entire-Checkpoint: トレーラーの値を抽出します。チェックポイント ID は重複を除去します。

一意のチェックポイント ID ごとに（最大20件）：

entire checkpoint explain --checkpoint <checkpoint-id> --json --no-pager

JSON を解析してセッションのメタデータを抽出します。各チェックポイント内のレビュー以外のセッションでは、要約（意図＋結果）を優先します。要約がない場合は、最新のユーザープロンプトを使用します。各チェックポイントの詳細は320文字に切り詰めます。

チェックポイントに対する --json が失敗した場合は、人が読みやすい形式のみの出力にフォールバックします。

entire checkpoint explain --checkpoint <checkpoint-id> --no-pager

レビューのワークフローでは --full を使用しないでください。長い説明文が出力されるため、エージェントが一括で解析しにくくなります。それも失敗した場合は、そのチェックポイントをスキップし、利用できなかったことを記録してください。

また、未コミットの作業のコンテキストを得るため、現在進行中のセッションがあれば読み取ってください。

entire session current --json

有効な JSON が返された場合は、last_prompt と files_touched を抽出します。これらは、まだどのチェックポイントにも記録されていない未コミット変更の意図を表します。

意図マップを作成します。差分内の各ファイル（コミット済み＋未コミット）について、そのファイルに関連する、変更に関わったすべてのチェックポイントとアクティブなセッションから意図のコンテキストを収集します。

5. 差分の確認

git diff <base>..HEAD

未コミットの変更も含めます。

git diff HEAD

差分が大きい場合（合計5000行超）は、最も重要なファイルを優先します。

• 変更量が最も多いファイル
• チェックポイントの意図で言及されているファイル
• 生成ファイルや設定ファイルよりもソースファイル

差分全体を一度に読み込むのではなく、必要に応じて個別ファイルの差分を確認してください。

6. レビューを実施する

レビューのルールを確認します。

references/review-rules.md

差分に含まれる各ファイルについて、次の点を考慮してレビューします。

チェックポイントのコンテキストがある場合：

• 実装は示された意図に沿っていますか？
• トランスクリプトに記載された制約は守られていますか？
• エージェントが議論したエッジケースを見落としていませんか？
• デバッグ用の残骸や TODO が残っていませんか？

常に確認する項目（コンテキストの有無を問わず）：

• ロジックエラー、オフバイワン、null 安全性
• セキュリティ上の問題（インジェクション、認証の回避、データ漏えい）
• パフォーマンス上の懸念（N+1 クエリ、不要なメモリ割り当て）
• エラーハンドリングの不足
• API コントラクト違反
• デッドコードまたは到達不能な分岐

7. 指摘事項を出力する

entire review --fix パーサーに対応した重要度プレフィックスを使用して、指摘事項を提示します。

Entire Review:

Reviewing <branch> vs <base>: N commits, M files changed
[Intent context: available from K checkpoints | unavailable — reviewing diff only]

## path/to/file.ts

Critical: <issue description>
  Intent: <what the checkpoint said this should do, if available>
  Actual: <what the code actually does>
  Fix: <concrete suggestion>

High: <issue description>
  Intent: <what the checkpoint said this should do, if available>
  Actual: <what the code actually does>
  Fix: <concrete suggestion>

Medium: <improvement opportunity>
  Issue: <what is wrong>
  Fix: <concrete suggestion>

## path/to/other-file.ts

Low: <observation that is not a bug but worth noting>

---

Found N issues (X critical, Y high, Z medium, W low).
Would you like me to create a fix plan for the critical and high issues?

指摘事項のチェックポイントコンテキストが利用できない場合は、Intent: 行を省略し、代わりに Issue: / Fix: を使用します。

8. フォローアップを提案する

指摘事項を提示した後、ユーザーの返答を待ちます。

• 修正計画を求められた場合は、各重大／高重要度の問題に対処する具体的な手順を示します。
• 直接修正するよう求められた場合は、実装モードに切り替えて問題に対処します。
• 断られた場合は、レビューを完了します。

機能制限モード（Entire CLI がない、またはチェックポイントがない場合）

チェックポイントのコンテキストが利用できない場合：

1. 手順 4 を完全にスキップします
2. スコープバナーに「意図のコンテキストを利用できません — 差分のみをレビューしています」と記載します
3. 指摘事項から「Intent:」行を省略します
4. 手順 6 のコードレベルのレビューは引き続きすべて実施します
5. 最後に次のように記載します：「このレビューは Entire のチェックポイントコンテキストなしで実施されました。チェックポイントが有効であれば、実装が開発者の当初の意図に沿っているかどうかも確認できます。」

失敗時の対応

• ベースと HEAD の間にコミットがない場合：ベースに対してブランチに変更がないことをユーザーに伝えます。レビューは出力しません。
• ベース参照を検出できない場合：ベースブランチまたはコミットを指定するようユーザーに依頼します。
• 差分が大きすぎる場合（100 ファイル超）：すべてのファイルをレビューするか、一部に絞るかをユーザーに尋ねます。ソースファイルのみ、またはチェックポイントコンテキストのあるファイルのみのレビューを提案します。
• entire checkpoint explain が失敗した場合：該当するチェックポイントを利用できなかったことを記録し、そのコンテキストなしで残りのファイルのレビューを続けます。