ce-code-review

コードレビュー

呼び出し元が、合意した範囲内で正しい変更を提供できるよう支援します。対応するだけの意義がある影響をもたらす欠陥や改善点を見つけ、好みの書き直し方ではなく、意図された動作とプロジェクト要件に照らしてコードを評価してください。差分が小さくても、重大な欠陥は重要です。指摘事項がない変更も、十分な変更です。

完了条件： 必要なレビューと検証が完了し、残した指摘事項がソースによって裏付けられており、残っているカバレッジの制限を含め、呼び出し元に明確な結果が伝わっていること。呼び出し時に変更が許可されている場合に限り、以下のルールに従って適用してください。

成果物のルート

成果物のパスを組み立てる前に、CE 成果物のルート <root> を解決してください。

• 読み取り： <repo-root>（<repo-root> = git rev-parse --show-toplevel）の .compound-engineering/config.yaml の docs_root のみを読み取ってください。config.local.yaml からは読み取らないでください。設定されていない場合、これまでどおり <root> は docs です。
• 検証： 値が設定されている場合は、リポジトリ相対のディレクトリであり、シンボリックリンクを解決した実際のパスがリポジトリ内にとどまり、リポジトリルートでも .git/ 配下でもないことを確認してください。それ以外の場合は、docs_root とその値を示すエラーで停止してください。docs にフォールバックしてはいけません。
• 使用： <root> のみを成果物の保存先として使用してください。存在しない場合は作成し、各パスをこのスキル固有のサブディレクトリを使って <root>/<subdir> として組み立ててください。docs を併せて読み取ることも禁止です。

実行手順

以下の手順を順番どおりに実行してください。参照先には詳細が記載されていますが、順序を変更することはありません。各手順を開始した時点で、その手順の作業を規定する参照先を読み取ってください。その手順より前に読み取っても、要件を満たしたことにはなりません。また、リーフに渡しただけで、自分では読んでいない参照先も対象外です。

1. まず references/modes-and-output.md を読みます。このファイルでは、引数、競合、クイックレビューのショートサーキット、Review の深度ゲート、およびこの呼び出しが返す内容を定めています。
2. Stage 1. references/scope.md を読み、レビュー対象の差分、スコープモード、決定的なスコープシグナルを特定します。その後、Stage 2 に進む前に Review の深度ゲートを適用します。Lite では後続の主要リファレンスを読むことなく実行を終了します。Lite と focused はそれぞれ、このコンテキストから references/depth-paths.md に従って実行します。
3. Stage 2. references/intent-and-plan.md を読み、すべてのレビュアーに渡すインテントの要約を作成し、Stage 6 で要件との照合に使う計画を特定します。
4. Stage 3. references/persona-catalog.md と references/select-and-route.md を読み、変更に伴うリスクに応じてレビュアーを選び、適用される標準ファイルを見つけ、敵対的レビューの実施方法を決定します。
5. Stage 3d. ローカルのレビュー対象ツリーで敵対的レビューを選択した場合、references/cross-model-review.md が定める認可済みのクロスモデルジョブを、ローカルのペルソナをディスパッチする前に開始し、永続化します。このスキルの呼び出し自体が、送信先とマシン外に出るコードについて必要な開示を行った後、設定済みまたは許可リストに登録されたピアルートを使う許可となります。ユーザーに再度確認を求めたり、ユーザーがその許可を繰り返さなかったことを理由にピアを省略したりしないでください。ユーザーが外部レビューを明示的に禁止している場合、またはチェックアウトで cross_model_review_mode: off が設定されており有効なオプトインがない場合は、ピアルートを設定する前に解決します。この段階で開始したピアはローカルの敵対的レビュアーに置き換わります。スコープの特定、許可リストの確認、到達、認証、または開始に実際に失敗した場合に限り、ローカルのフォールバックをロスターに残します。リファレンスに記載された条件を満たせば、後続の段階でローカルレビュアーを再度加えることができます。
6. Stage 4. references/dispatch-reviewers.md を読みます。選択したローカルレビュアーを、このターンでまとめて収集する同時バッチとしてディスパッチし、ホストのアクティブエージェント上限に合わせてサイズを調整します。正常に起動した各レビュアーの結果を収集するのは、最終的な結果を受け取ってからに限ります。有効な簡潔な戻り値は採用し、ツールエラーまたは形式不正な出力は失敗したレビュアーとして記録します。起動確認だけでは結果になりません。非同期の受領結果には、リファレンスに記載された上限内でホストのブロッキング収集機能を使用します。それを過ぎても未収集のレビュアーは失敗とします。最終結果は、呼び出しの戻り値、ブロッキング待機の戻り値、または起動名とペイロードを含むホスト配信の最終メッセージとして届く場合があります。進捗更新は最終結果ではありません。起動した作業を確実に収集できない場合は停止します。永続化されたピア（クロスモデルジョブ）がある場合は、失敗結果を返す前に、そのリファレンスで定めるクリーンアップを実行してください。進捗を理由にターンを終了し、結果を待つことはしないでください。ローカルレビューをポーリング式のバックグラウンドジョブに切り離すことは禁止されています。切り離しが許されるのはクロスモデルのピアだけであり、ピアはこのバッチと並行して実行できます。
7. Stages 5 and 6. すべてのレビュアーの結果がそろったら、references/finish-input.md で定める仕上げ入力を作成し、同リファレンスに従います。バリデーターの起動と実行アーティファクトのリストは、このリファレンスで扱います。そこに指定された 2 つのリーフサブエージェントを順番にディスパッチし、それぞれに references/finish-review.md を渡します。リーフはこのファイルをディスクから読み込みます。あなた自身は開きません。まずマージリーフを起動し、実行ディレクトリからマージして、ピアの指摘を一度だけ取り込みます。次に、選択したバリデーターを起動して結果を収集し、その後、レポートリーフを起動してレポートを生成します。どちらのリーフもサブエージェントを起動しません。すべての起動はあなたが行います。このスキルの応答として、レポートリーフの戻り値を一字一句そのまま出力します。生のレビュアーアーティファクトから直接内容を作成したり、ディスパッチコンテキスト内でマージやレポート生成を行ったりしてはいけません。マルチエージェント経路では、このスキルのレポートだけを出力します。クイックレビューのショートサーキット専用であるハーネス標準の指摘・レポートツールも併せて呼び出してはいけません。

運用原則

• デフォルトでは報告のみ。プッシュは決して行いません。 ce-code-review を単独で実行すると、指摘事項を報告し、修正は適用しません。適用ステージに進むには、apply:local を指定するか、実行時のプロンプトで、このレビューの指摘事項を適用または修正するようユーザーから明示的に依頼されている必要があります。非推奨の mode:autofix トークンは、どちらにも該当しません。mode:agent は、後続のワークフローで指摘事項が適用される場合でも、ツリーを変更しません。どのモードでも、プッシュ、PR の作成、チケットの起票は決して行いません。
• 処理を止める質問はしません。 AskUserQuestion、request_user_input、ask_user、その他の処理を止める質問ツールは決して使用しません。明示的なトークン、git の状態、PR のメタデータ、会話から、意図、計画、範囲を推測します。不確かな点は Coverage または判定に記載し、質問のために処理を止めないでください。
• 明示された変更のみを行います。 gh pr checkout、git checkout、git switch、その他の同様のブランチ切り替えコマンドは決して実行しません。PR 番号、URL、ブランチ名の指定はレビュー対象範囲を選ぶものであり、作業ツリーを変更する許可ではありません。未コミットの作業は、それを保持しているチェックアウトからしかレビューできません。そのため、フィーチャーブランチ上でレビューする場合は、そのブランチにとどまる（または自分でチェックアウトする）うえで、base: またはターゲットなしを指定してください。
• 仕組みではなく、結果を報告します。 ユーザーに伝える内容はレビューに関するものです。何を調べているか、対象に含まれる範囲と条件付きの各観点についての一行の理由、独立したクロスモデルレビュー、指摘事項を示してください。PR 番号、レビュー担当者の懸念、ピアモデルなど、ユーザーが認識できる名称を挙げてください。このスキル内部のラベル、ディスパッチの記録、セットアップに関する説明は、ユーザー向けの文章に含めません。ピアモデルについては、その受領記録が裏付ける範囲を超えて主張しないでください。この原則は、何を提示し、何を伏せるかを定めるものであり、言い回しを定めるものではありません。表現は自分の言葉を使ってください。