| name | open-code-review |
| description | Performs AI-powered code review on Git changes using the `ocr` CLI from alibaba/open-code-review. Use when the user asks to review code, review a pull request, review staged/unstaged changes, review a commit, or compare branches for code quality issues. Produces line-level review comments and can automatically apply fixes when requested. With appropriate review rules, can detect various types of issues including bugs, security vulnerabilities, performance problems, and code quality concerns.
|
| license | Apache-2.0 |
| compatibility | Requires the `ocr` CLI installed (via `npm install -g @alibaba-group/open-code-review` or GitHub release binary). Requires a configured LLM (Anthropic or OpenAI-compatible) before first run.
|
| metadata | {"author":"alibaba","homepage":"https://github.com/alibaba/open-code-review","version":"1.0.0"} |
Open Code Review
A skill for invoking open-code-review (ocr) — an open-source AI code review CLI that reads Git diffs and generates structured, line-level review comments.
Prerequisites check
Before starting a review, verify the environment:
which ocr || echo "NOT INSTALLED"
ocr llm test
If ocr is not installed, install it first:
npm install -g @alibaba-group/open-code-review
If ocr llm test fails, the user must configure an LLM. Guide them with one of these options:
Option A — Environment variables (highest priority, recommended 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
Option B — Persistent config:
ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token <api-key>
ocr config set llm.model claude-opus-4-6
ocr config set llm.use_anthropic true
Stop here and ask the user to provide credentials — never invent or hardcode API keys.
Workflow
Step 1: Gather Business Context
Before running the review, inspect the review target (commits, branch, working copy) and synthesise a short --background string that captures the intent of the changes. This improves review quality by giving the LLM context about what the code is trying to achieve.
Step 2: Run Code Review
- Preview mode: use
--preview or -p to preview which files will be reviewed without running the LLM
- Installation: if
ocr command is not found, install it by running npm i -g @alibaba-group/open-code-review
Common invocation patterns:
| User says | Command to run |
|---|
| "review my changes" / "review the working copy" | ocr review --audience agent -b "context" |
| "review this PR" / "review feature branch" | ocr review --audience agent -b "context" --from main --to <branch> |
| "review commit abc123" | ocr review --audience agent -b "context" --commit abc123 |
| "what would be reviewed?" (dry-run) | ocr review --preview |
Output mode:
- Always use
--audience agent to suppress progress UI and emit only the final summary
Step 3: Classify and Report
Group the JSON comments into High / Medium / Low using the rubric below, then render a Markdown summary.
| Severity | Criteria |
|---|
| High | Bugs, security vulnerabilities, data loss risks, correctness issues |
| Medium | Performance problems, maintainability concerns, test gaps, unclear logic |
| Low | Style nits, minor naming suggestions, documentation improvements |
Nitpicks and likely false positives are silently dropped.
Step 4: Fix
If the user said "review and fix" (or similar), apply safe fixes to High/Medium items inline. Otherwise ask before touching the code.
Output Format
Each comment follows this structure:
| Field | Type | Required | Description |
|---|
| path | string | yes | Relative file path |
| content | string | yes | Review comment describing the issue |
| start_line | integer | no | Start line in the new file |
| end_line | integer | no | End line in the new file |
| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |
| severity | enum | no | critical, high, medium, low |
Custom Review Rules
OCR supports custom review rules via .ocr-rules.yaml in the repo root. Rules can target specific file patterns and define review checklists. See the Review Rules docs for the full schema.
Gotchas
- LLM must be configured first —
ocr review will fail loudly if no LLM is reachable. Always run ocr llm test before the first review.
- Working directory matters —
ocr review operates on the Git repo at the current directory. Use --repo /path/to/repo to run from elsewhere.
- Untracked files are reviewed in workspace mode — running bare
ocr review includes staged, unstaged, and untracked changes. Stage selectively if you want narrower scope.
- Large diffs may hit token limits — files with very large diffs may be truncated. The default
MAX_TOKENS is 58888 per request.
- Plan phase triggers at 50 lines — diffs exceeding 50 changed lines run an extra risk-analysis phase before main review. This adds latency but improves quality.
- Don't pass
--audience human — it streams progress UI that pollutes output. Always use --audience agent.
Validation
After the review completes, verify success by checking:
- The command exited with code 0
- Comments were generated (or "No comments generated" message appears)
- Warnings (if any) are displayed in stderr
If errors occurred, check the stderr warnings for details about which files failed and why.
References
