open-code-review-delegate

Open Code Review — 委任モード

AI コードレビューを実行するためのスキルです。OCR が決定論的なエンジニアリング（ファイルのフィルタリング、ルールの解決）を提供し、ホストエージェントが自身の知能とツールを使って実際のレビューを実行します。

ワークフロー

ステップ 1: プレビュー — レビュー対象を特定する

ocr delegate preview --format json [--from <ref> --to <ref>] [--commit <hash>] [--exclude <patterns>]

出力内容:

• mode (workspace / range / commit)
• from / to / commit / merge_base — git コマンドを構築するための ref メタデータ
• レビュー可能なファイル一覧 — パス、ステータス、追加/削除行数
• 除外されたファイル — 除外理由付き

一般的な呼び出し:

シナリオ	コマンド
ワークスペースの変更	ocr delegate preview
ブランチの比較	ocr delegate preview --from main --to feature
単一コミット	ocr delegate preview -c abc123

ステップ 2: ファイルのルールを取得する

ocr delegate rule --format json <path1> <path2> ...

ステップ 1 で得たレビュー可能なファイルパスを渡します。出力はルールの内容ごとにグループ化されます — 同じルールを共有するファイルは 1 つのグループにまとめて表示され、重複を避けます。

ステップ 3: 差分を取得する

ステップ 1 のモードと ref を使って差分コマンドを選択します。レビュー中のすべての Git 呼び出しには git --no-pager を使用してください。

差分コマンドは、外部差分プログラム、テキスト変換、色を無効にして、プレーンなパッチを生成します。

レンジモード（プレビュー出力で merge_base が提供される場合）:

git --no-pager diff --no-ext-diff --no-textconv --no-color <merge_base>..<to> -- "<path>"

コミットモード:

git --no-pager show --no-ext-diff --no-textconv --no-color <commit> -- "<path>"

ワークスペースモード:

# Tracked files
git --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- "<path>"
# New untracked files — read directly (entire file is new code)
cat "<path>"

コンテキストを読み取るには:

git --no-pager log --no-color --oneline -- "<path>"
git --no-pager blame --no-textconv -- "<path>"
git --no-pager show --no-ext-diff --no-textconv --no-color "<ref>:<path>"

大きな差分の場合、選択したモードのコマンドに --output="<absolute-diff-file>" を追加します。リポジトリ外の一意な絶対パスを選び、その親ディレクトリを作成してください。ファイル読み取りツールの呼び出しでも同じパスを使用します:

git --no-pager diff --no-ext-diff --no-textconv --no-color --output="<absolute-diff-file>" <merge_base>..<to> -- "<path>"

Git がコード 0 で終了したら、ファイル全体をチャンク単位で読み取ってレビューし、その後削除します。Git が失敗したかタイムアウトした場合は、再試行するか、エラーとともに skipped として記録します。予期せず空の出力になった場合は、新たにプレビューして突き合わせて確認してください。

ステップ 4: 各ファイルをレビューする

すべての reviewable_files エントリを含むチェックリストを作成します。レビュー可能な各ファイルについて:

チェックリストの識別子として (path, status) を使用します。ワークスペースモードでは、ステージされた削除の後に未追跡の再作成が続く場合、同じパスが 2 回報告されることがあります。

1. その差分を取得する（ステップ 3）
2. レビューチェックリストのためにそのルールグループ（ステップ 2 より）を参照する
3. 必要に応じて適切なコンテキストツールを使い、徹底的にレビューする
4. ファイルを reviewed としてマークするか、具体的な理由とともに skipped としてマークする

大きな変更の場合、共有ルールと差分サイズでグループ化した適度なバッチ単位でレビューします。最初の高重大度の問題を見つけただけで止めないでください。

ステップ 5: 出力をフォーマットする

各コメントは次の構造に従う必要があります:

フィールド	型	必須	説明
path	string	yes	相対ファイルパス
content	string	yes	問題を説明するレビューコメント
start_line	integer	no	新しいファイルでの開始行
end_line	integer	no	新しいファイルでの終了行
category	enum	no	bug, security, performance, maintainability, test, style, documentation, other
severity	enum	no	critical, high, medium, low

ステップ 6: 分類して報告する

報告する前に、プレビューされたすべてのファイルが漏れなく処理されていることを確認してください。サマリーに total_files、reviewed_files、skipped_files、coverage_rate を含めます。スキップされたファイルにはその理由を含める必要があります。

検出事項を重大度別にグループ化します:

• Critical/High: バグ、セキュリティ問題、データ損失のリスク — 常に報告する
• Medium: パフォーマンスの懸念、エラー処理の不足、保守性の問題 — コンテキストとともに報告する
• Low: スタイルの細かい指摘、軽微な提案 — 明らかに価値がある場合のみ報告する

誤検出の可能性が高いものは黙って破棄します。

ステップ 7: 修正（任意）

ユーザーが「レビューと修正」を依頼した場合:

• High/Critical の修正を直接適用する
• 手動での介入が必要な Medium の修正について説明する
• Low 優先度の項目は、些細なものでない限りスキップする

サブコマンドリファレンス

コマンド	目的
ocr delegate preview	レビュー対象のファイル + モード/ref メタデータ
ocr delegate rule <path...>	コンテンツごとにグループ化されたレビュールール

共通フラグ

フラグ	説明
--from <ref>	範囲モードのソース ref
--to <ref>	範囲モードのターゲット ref
-c, --commit <hash>	単一コミットモード
--repo <path>	リポジトリルート（デフォルト: cwd）
--rule <path>	カスタム rule.json のパス
--exclude <patterns>	カンマ区切りの除外パターン
-b, --background <text>	ビジネスコンテキスト
-B, --background-file <path>	Markdown ファイルからのビジネスコンテキスト（-b より優先されます）
-f, --format <text|json>	出力形式。エージェント連携には json を使用してください

注意点

• OCR 側に LLM は不要 — 委任モードは LLM を呼び出しません。すべてのインテリジェンスはホストエージェントから提供されます。
• ルールはグループ化される — 同じルールを共有するファイルは出力内でグループ化されます。1 回の呼び出しで任意の数のパスを渡せます。大規模な変更の場合は、レビューを進めながらバッチごとにルールを取得してください。
• 作業ディレクトリが重要 — ocr delegate は現在のディレクトリにある Git リポジトリに対して動作します。上書きするには --repo /path を使用してください。
• ワークスペースモードでの未追跡ファイル — preview には未追跡ファイルが含まれます。これらについては、git diff を使うのではなくファイルを直接読み取ってください。
• バックグラウンドコンテキスト — 要件のコンテキストがある場合は preview に --background を渡してください。レビュー中の参照用として出力に表示されます。
• カバレッジは必須 — すべての reviewable_files エントリは、レビュー済みまたは明示的にスキップされた状態で終える必要があります。ファイルを黙って省略しないでください。

大きすぎるバックグラウンドコンテキストの復旧

--background-file には 2 つの独立した制限があります。生のファイルは 1 MiB を超えてはならず、サニタイズされたコンテンツは 8000 文字を超えてはなりません。どちらかの 条件に該当するとコマンドは中断されます。コマンドがいずれかの制限を報告した場合:

1. ソースファイルを黙って切り詰めないでください。
2. 要件、制約、受け入れ基準、その他のレビューに重要な詳細を保ちながら、 元の資料を要約してください。
3. 影響を受けたコマンドを、要約を 1 つのシェルセーフな 引数として渡して再試行してください（たとえば、ホストシェルが生成した 引用符付き/エスケープ済みの引数を使用するか、サイズ制限内の新しいファイルに書き出してそのファイルを渡します）。信頼できない要約テキストを 二重引用符で囲まれたシェルテンプレートに直接配置しないでください。 $()、バッククォート、引用符、変数参照は依然として評価される可能性があります。 元の --background-file を省略して、CLI が同じ 大きすぎるファイルを再読み込みして再び失敗しないようにしてください。
4. 忠実な要約が不可能な場合は、OCR のバックグラウンドを完全に省略し、 レビュー中に元の資料を直接読んでください。

CLI バージョン互換性のトラブルシューティング

--format フラグは ocr v1.9.0 以降で利用できます。Skill と インストール済みの CLI は独立して更新できます。--format json を指定した preview または rule コマンドが、特に unknown flag: --format で失敗した場合は、 そのフラグを付けずに再実行し、委任実行の残りではテキスト出力を使用してください。 その出力から明示的なモード、ref、ファイル、ルールの情報を保持してください。 テキスト出力を JSON として解析したり、欠落しているスキーマフィールドを捏造したりしないでください。 その他のエラーではフラグを付けずに再試行しないでください。そのエラーを報告し、影響を受ける ワークフローを停止してください。

ホストエージェントの Skill は、レビューチェックリストを完了するために 同等のテキスト出力を消費する場合があります。schema_version やその他の JSON フィールドを 必要とするプログラムによる連携では、代わりに JSON 対応の CLI が必要です。 ocr --version で確認し、必要に応じてアップグレードしてください:

npm install -g @alibaba-group/open-code-review