Name: open-code-review
Author: alibaba

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 au

Open Code Review A skill for invoking [open code review](https://github.com/alibaba/open code review) ( ocr ) — an open source AI code review CLI that reads Git diffs and generates structured, line level review comments. Workflow Step 1: Gather Business Context Analyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via background to improve review quality. Step 2: Run Code Review Do not pre check whether ocr is installed — skip probes like command v ocr or ocr version . Assume the CLI is available and run the review directly; that saves a tool call on the common path. Only if the review fails with command not found should you install it per Troubleshooting. Run the OCR command with appropriate flags. Always pass business context via background when available: Argument handling: Background context (RECOMMENDED): use background "context" or b "context" to provide business context for better review quality Default (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode) Specific commit : use commit or c to review a single commit against its parent Branch comparison : use from <ref and to <ref to review diff between two refs Timeout : effective timeout per review group = timeout × review rounds. Default timeout 15 with default effort medium (2 rounds) gives 30 minutes; low / high give 15/45 minutes. Concurrency : default concurrency is 8 file workers; reduce with concurrency <n if rate limits are hit Preview mode : use preview or p to preview which files will be reviewed without running the LLM Output file : use output <path to write the full result to a file instead of stdout. If the command fails with unknown flag: output , do not continue the review with plain stdout. Ask the user whether to upgrade ( npm i g @alibaba group/open code review@latest ) and wait for the answer before proceeding. After the user confirms and the upgrade succeeds, rerun with output . 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 Prevent output truncation : For large reviews or restricted tool environments, pass output /tmp/ocr out.txt and inspect the file in full via a file reading tool instead of piping stdout through tail or head , which drops earlier review comments. On failure: If ocr review exits non zero (e.g. an LLM connection error), do not retry blindly — consult the Troubleshooting section below for the matching fix before re running. Step 3: Report OCR output includes structured severity (critical / high / medium / low) and category (bug / security / performance / maintainability / test / style / documentation / other) on each comment. Present results grouped by severity, discarding low severity items that are likely false positives or nitpicks. Step 4: Fix Before applying fixes, check whether the user requested automatic fixes: If the user explicitly requested "review and fix" or similar, proceed with automatic fixes If the user only requested "review" without fix intent, ask for permission before applying any changes When fixing issues and suggestions: Focus on critical, high, and medium severity items Apply fixes directly to the code when safe and well defined For complex fixes requiring manual intervention, clearly describe what needs to be done Always verify fixes with the user before committing Output Format Each comment in OCR's output contains: path : File path content : Review comment text start line / end line : Line range (both 0 means positioning failed) category : Issue category (bug, security, performance, maintainability, test, style, documentation, other) severity : Issue severity (critical, high, medium, low) suggestion code : Optional fix suggestion existing code : Optional original code snippet thinking : Optional LLM reasoning process Present results grouped by severity using this template: If no critical, high, or medium severity issues remain after filtering, state: "Review complete — no critical, high, or medium issues found in N files." Handling mispositioned comments: When start line and end line are both 0 , the comment failed to locate the exact position in the file. In such cases: 1. Read the comment content to understand the issue 2. Examine the target file mentioned in the comment 3. Identify the relevant code section based on the comment's context 4. Apply the fix or suggestion to the correct location Custom Review Rules If the user wants project specific rules, OCR resolves them in this priority order: 1. rule <path flag (highest) 2. <repo /.opencodereview/rule.json 3. ~/.opencodereview/rule.json 4. Built in system defaults (lowest) By default, the first matching user rule replaces the built in system rule. Set merge system rule: true on a rule entry when the matched system rule and user rule should both be included. Rule file format: To preview which rule applies to a file before reviewing: Advanced Review Options Beyond the common flags above, ocr review exposes a few groups of controls. Run ocr review help for the complete list. Scoping exclude '<patterns ' — comma separated gitignore style patterns (for example exclude ' /generated/ , /testdata/ ' ), merged with rule.json excludes. background file <path — read review context from a Markdown file. Takes precedence over background . Output format text json sarif — text (default) for humans; json for machine readable findings; sarif for code scanning integrations such as GitHub Code Scanning. Model provider <name / model <name — override the configured provider/model for this run only (for example, to recheck a diff with a different model; the user names the model, ocr llm providers lists the built ins). Budget max tokens <n — per group prompt ceiling; defaults to the configured value or the template default ( 200000 ). max tokens budget <n — cap total input + output tokens for the run. Checked before every LLM round: a group already over budget gets one final round to submit findings, no further groups are dispatched, partial results are still published, and skipped files are reported as failed(budget) . no filter — keep all review comments and skip the LLM post filtering call. Gotchas LLM must be configured first — ocr review will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens. 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 — MAX TOKENS sets the prompt budget ( 200000 in the review template; ocr scan uses 58888 ); conversation context is compressed to stay within this prompt budget. Model output is capped separately by MAX COMPLETION TOKENS ( 16384 ). A file whose diff alone exceeds ~80% of MAX TOKENS is skipped before the LLM is called. Plan phase triggers on either of two thresholds — a group runs an extra risk analysis phase before main review when its largest changed file reaches PLAN MODE LINE THRESHOLD (default 50 ) or it holds 2+ files whose combined changed lines reach PLAN MODE GROUP LINE THRESHOLD (default 100 ). This adds latency but improves quality. Don't pass audience human — it streams progress UI that pollutes output. Always use audience agent . Comment language follows config — the language config controls review comment language, defaults to English , and accepts any language name (for example English or 中文 ). Avoid output truncation — Large review runs produce verbose output. Never pipe command output to tail or head as it drops review comments from earlier sections. Use output <path and read it in full; on older CLIs, follow the Output file guidance above. Resume an interrupted review — a failed or interrupted range/commit review can be continued with ocr review resume <id using the same from / to or commit target (the id is printed as retry with: resume <id on failure, or find it with ocr session list ). Workspace resume is not supported. Validation After the review completes, verify success by checking: 1. The command exited with code 0 2. Comments were generated (or "No comments generated" message appears) 3. Warnings (if any) are displayed in stderr If errors occurred, check the stderr warnings for details about which files failed and why. Troubleshooting ocr: command not found Install the CLI: unknown flag: output The CLI is older than v1.10.0. Do not continue the review with plain stdout. Ask the user whether to upgrade ( npm i g @alibaba group/open code review@latest ) and wait for the answer before proceeding. After the user confirms and the upgrade succeeds, rerun with output . ocr review fails with LLM connection error Prompt the user to configure an LLM provider. Interactive setup (recommended): Manual setup (alternative): Verify connectivity with ocr llm test . Stop here and ask the user to provide credentials — never invent or hardcode API keys. References Full docs: https://github.com/alibaba/open code review NPM package: https://www.npmjs.com/package/@alibaba group/open code review Issue tracker: https://github.com/alibaba/open code review/issues