mcpField
O
open-code-review

open-code-review

github.com/akillnessテスト・品質5398 回インストール今日更新
リポジトリ

open-code-review について

open-code-reviewは、`ocr` CLIを操作するためのスキルです。設定済みのLLMでGit差分やファイル全体を調べ、行単位のコメントを生成します。適切な実行方法を選び、業務の背景を加えて指摘を分類し、明示的な依頼がある場合のみ修正します。

主な機能

  1. 01作業ツリー・コミット・ブランチ差分のレビュー
  2. 02ファイル全体のコードスキャン
  3. 03--backgroundによる業務背景の指定
  4. 04行単位の指摘を優先度別に整理
  5. 05必要に応じてエージェントやCI/CDへ接続
  6. 06明示的な依頼がある場合のみ修正・検証

活用シーン

  1. 01未コミットの作業ツリー変更を確認する
  2. 02コミットやPR/MRのブランチ差分をレビューする
  3. 03不慣れなコードや移行前のコードをスキャンする
  4. 04自動レビューをエージェントやCI/CDに組み込む

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/akillness/jeo-skills --skill open-code-review

インストール後、Claude Code で/open-code-reviewを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

SKILL.toon
evals/
evals.json
references/
cicd-and-plugins.md
configuration-and-rules.md
intake-and-modes.md
scripts/
run-scan.sh
install.sh
run-review.sh

詳細

Open Code Review — ocr CLI によるルーティング優先の AI レビュー

キーワード:open-code-review · ocr review · ocr scan

OpenCodeReview (OCR) は、Alibaba のオープンソース AI コードレビュー CLI です。Git の差分(またはファイル全体)を読み取り、設定された LLM を通じて、行単位の構造化されたレビューコメントを生成します。

このスキルは、ocr バイナリを操作するための窓口です。ユーザーの質問に答える最も軽量な呼び出し方法を選び、ビジネスコンテキストを補い、指摘事項を分類してから、修正を適用します。人間によるレビュー判断を再実装するものではありません。それは隣接する code-review スキルが担います。

このスキルを使う場面

  • ユーザーが、作業コピーの変更、コミット、ブランチ間の範囲、または PR/MR の自動レビューを希望している
  • ユーザーが、見慣れないコードベースや移行前のコードベースを監査するため、ファイル全体をスキャン(差分なし)したい
  • ユーザーが、コーディングエージェント(Claude Code / Codex のスラッシュコマンド)や CI/CD にレビューを組み込みたい
  • ユーザーが、ocr の LLM プロバイダー設定や接続テストのサポートを必要としている
  • ユーザーが、OCR のコメントを優先度別に分類し、一部を自動修正したい

このスキルを使わない場面

  • 証拠を重視した人間によるレビュー判断(承認/変更要求/ブロックの判断)→ code-review
  • コミットの分割、リベース、競合解決、プッシュの復旧 → git-workflow
  • 実行中の障害の再現または切り分け → debugging
  • 長期的なカバレッジ方針、CI ゲート、不安定なテストスイートの方針 → testing-strategies
  • 測定に基づくボトルネック分析 → performance-optimization

手順

ステップ 1:レビュー前に前提条件を確認する
which ocr || echo "NOT INSTALLED"   # CLI present?
ocr llm test                        # LLM reachable?

ocr がない場合は、環境に必要なものだけをインストールします。

bash scripts/install.sh --method npm         # global npm install (default)
bash scripts/install.sh --method release     # GitHub release binary (macOS/Linux)
bash scripts/install.sh --method source      # build from source with make

ocr llm test が失敗した場合は、ユーザーがプロバイダーを設定する必要があります。API キーを決して捏造したり、ハードコードしたりしないでください。処理を止めてユーザーに認証情報を求め、その後、次のいずれかの方法を使います。

# Interactive (recommended for humans)
ocr config provider
ocr config model

# Non-interactive (CI/scripts) — built-in provider
ocr config set provider anthropic
ocr config set providers.anthropic.api_key <api-key>
ocr config set providers.anthropic.model claude-sonnet-4-6

# Environment variables (highest priority — best for CI)
export OCR_LLM_URL=https://api.anthropic.com/v1/messages
export OCR_LLM_TOKEN=<api-key>
export OCR_LLM_MODEL=claude-opus-4-6
export OCR_USE_ANTHROPIC=true

プロバイダーと設定の詳細は、references/configuration-and-rules.md にあります。

ステップ 2:呼び出し前にビジネスコンテキストを収集する

コミットメッセージ、ブランチ名、またはユーザーが示した意図を読み取り、要件を短い一文にまとめます。--background(-b)で渡してください。OCR はこれを使って、コードが解析できるかどうかだけでなく、変更が要件を満たしているかどうかを判断します。

ステップ 3:要件に合う最も軽量な呼び出し方法を選ぶ

主モードを必ず 1 つだけ選びます。

ユーザーの意図コマンド
作業コピーをレビューする(ステージ済み+未ステージ+未追跡)bash scripts/run-review.sh -b "context"
1 つのコミットをレビューするbash scripts/run-review.sh --commit <sha> -b "context"
2 つの参照を比較する(PR/フィーチャーブランチ)bash scripts/run-review.sh --from <base> --to <head> -b "context"
ドライラン:レビュー対象となるファイルを確認するocr review --preview
意味のある差分がない状態でファイル全体を監査するbash scripts/run-scan.sh --path <dir>

ラッパースクリプトは、デフォルトで --audience agent を指定します。これにより進行状況 UI が抑制され、最終サマリーのみが出力されます。エージェントが(人間のターミナルではなく)出力を利用する場合に適したモードです。

# Workspace review with context
bash scripts/run-review.sh -b "Adding rate limiting to the login API"

# Branch range, JSON output for parsing, lower concurrency to dodge rate limits
bash scripts/run-review.sh --from origin/main --to feature-x --format json --concurrency 4

# Single commit; --background auto-fills from the commit message when omitted
bash scripts/run-review.sh --commit abc123

# Full-file scan of a subdirectory, capped spend, skipping generated/test files
bash scripts/run-scan.sh --path internal --exclude '**/*_test.go,**/generated/**' --max-tokens-budget 500000

レビュー/スキャンのフラグに関するリファレンスは、references/intake-and-modes.md にあります。

ステップ 4:指摘事項を分類して報告する

OCR は、path、content、start_line/end_line(両方が 0 の場合は位置の特定に失敗)、任意の suggestion_code、existing_code、thinking を含むコメントを返します。優先度ごとにまとめます。

  • 高 — 明らかなバグ、セキュリティ上の問題、明確な誤り、または正確な提案を伴う根拠のある修正
  • 中 — 妥当だがコンテキストに依存する懸念、スタイル/パフォーマンスの提案、手動修正が必要な項目
  • 低 — 誤検出の可能性が高いもの、コンテキスト不足、些細な指摘。ユーザーがすべての指摘を求めていない限り、報告せずに破棄する

「高」と「中」は優先度ごとにまとめて報告し、それぞれに path:line を記載します。

ステップ 5:意図と検証を伴う修正のみ行う
  • ユーザーが明確に「レビューして修正」と依頼した場合は、安全かつ明確に定義できる High/Medium の修正を直接適用します
  • ユーザーが「レビュー」のみを依頼した場合は、コードを変更する前に確認します
  • 手作業が必要な複雑な修正については、推測せずに必要な作業を説明します
  • 関連するテスト/ビルドを必ず再実行し、コミットする前に修正内容をユーザーに確認します
ステップ 6:依頼があれば OCR をエージェントや CI に組み込む
  • スキルのインストール:npx skills add alibaba/open-code-review --skill open-code-review
  • Claude Code プラグイン:/plugin marketplace add alibaba/open-code-review の後に /plugin install open-code-review@open-code-review
  • Codex プラグイン:codex plugin marketplace add alibaba/open-code-review を実行し、次に /plugins で有効化します
  • CI/CD:ocr review --from "origin/main" --to "<commit_sha>" --format json(フォーク PR を解決できるように、--to にはコミット SHA を使用します)

プラグインと CI の組み込み方法については、references/cicd-and-plugins.md を参照してください。

出力形式

レビューを依頼された場合は、優先度別に簡潔にまとめて返します。

## Code Review Results

**Mode**: workspace | commit <sha> | <base>..<head> | scan
**Files reviewed**: N
**Issues**: X high / Y medium

### High priority
- **`path/to/file.go:42`** — what is wrong
  > Recommendation: how to fix

### Medium priority
- **`path/to/other.ts:88`** — concern + context

### Decision
- ran <command>; fixes applied | fixes proposed (awaiting approval) | route-out to <skill>

例

例 1:「変更をレビューしてください」

bash scripts/run-review.sh -b "<context>"(ワークスペースモード)を実行し、分類して報告します。

例 2:「この PR を main と比較してレビューしてください」

bash scripts/run-review.sh --from origin/main --to <branch> -b "<context>" を実行します。

例 3:「この見慣れないリポジトリに問題がないか監査してください」

まず bash scripts/run-scan.sh --preview を使ってファイル一覧とトークンの推定数を確認してから、スキャンします。

例 4:「コミット abc123 をレビューして、確度の高いバグを修正してください」

bash scripts/run-review.sh --commit abc123 を実行し、High の指摘事項に限って的確な修正を適用し、検証して確認します。

例 5:「GitHub Actions に OCR を追加してください」

references/cicd-and-plugins.md を案内し、ocr review --from origin/main --to <sha> --format json を使用します。

例 6:「このリスクの高い移行を承認すべきか判断するのを手伝ってください」

これはツールの使用ではなく、レビュー上の判断です。判断材料を得るために OCR を実行し、その後、判断を code-review に回します。

ベストプラクティス

  1. レビューを約束する前に、ocr がインストールされており、ocr llm test が成功することを確認します。
  2. 推測できる場合は、常に --background のコンテキストを指定します。関連性が大きく向上します。
  3. 実行モードは1つだけ選び、同じ質問に対してレビューとスキャンの両方を実行しないでください。
  4. 大規模な scan の前に --preview を使って、対象範囲とコストを見積もります。
  5. 機械処理には --format json と --audience agent を使い、ターミナルではテキスト/人間向けの出力を使用します。
  6. OCR のコメントは判断材料として扱い、最終的な結論とはみなさないでください。確信度の低いノイズは黙って除外します。
  7. API キーを捏造したりハードコードしたりしないでください。処理を止め、ユーザーに認証情報を尋ねます。
  8. 明確な意図があり、安全な High/Medium の項目に限って自動修正し、コミット前に検証します。
  9. 人間による承認/却下の判断は code-review に、Git のクリーンアップは git-workflow に、実行中のデバッグは debugging に回します。

参考資料

コメント