{"owner":"alibaba","repo":"open-code-review","hasSkills":true,"totalSkillsCount":19,"totalTokensCount":18635,"categories":["marketplace","command-prompt","plugin-manifest","root-instruction","claude-rule","anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":[".agents/plugins/marketplace.json",".claude-plugin/marketplace.json",".claude/commands/commit.md",".claude/commands/tag.md",".kimi-plugin/plugin.json","AGENTS.md","CLAUDE.md","extensions/idea/README.md","extensions/vscode/README.md","plugins/open-code-review/.codex-plugin/plugin.json","plugins/open-code-review/.cursor-plugin/plugin.json","plugins/open-code-review/README.md","plugins/open-code-review/claude-code/.claude-plugin/plugin.json","plugins/open-code-review/opencode/README.md","plugins/open-code-review/qca/README.md","plugins/open-code-review/skills/open-code-review-delegate/SKILL.md","plugins/open-code-review/skills/open-code-review/SKILL.md","skills/open-code-review-delegate/SKILL.md","skills/open-code-review/SKILL.md"],"skills":{".agents/plugins/marketplace.json":"{\n \"name\": \"open-code-review\",\n \"interface\": {\n \"displayName\": \"Open Code Review\"\n },\n \"plugins\": [\n {\n \"name\": \"open-code-review-codex\",\n \"source\": {\n \"source\": \"local\",\n \"path\": \"./plugins/open-code-review\"\n },\n \"policy\": {\n \"installation\": \"AVAILABLE\",\n \"authentication\": \"ON_INSTALL\"\n },\n \"category\": \"Developer Tools\"\n }\n ]\n}\n",".claude-plugin/marketplace.json":"{\n \"name\": \"open-code-review\",\n \"owner\": {\n \"name\": \"alibaba\"\n },\n \"description\": \"AI-powered code review agent that reads Git diffs, analyzes changed files with LLM tool-use capabilities, and generates structured line-level review comments with cross-referential context awareness.\",\n \"plugins\": [\n {\n \"name\": \"open-code-review\",\n \"source\": \"./plugins/open-code-review/claude-code\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\",\n \"license\": \"Apache-2.0\"\n }\n ]\n}\n",".claude/commands/commit.md":"# /commit\n\nPlease summarize your current changes, generate a commit message in English, then add and commit.\nNever include any AI tool or model as a Co-Author in commit messages. No `Co-Authored-By` lines referencing AI assistants.\n",".claude/commands/tag.md":"# /tag\n\nCreate an annotated git tag with an auto-generated summary of changes since the last tag.\n\n## Arguments\n\n- `$ARGUMENTS`: Optional version number (e.g., `v1.2.0`). If omitted, auto-increment the patch version from the latest tag.\n\n## Workflow\n\n### Step 1: Determine version\n\n1. Get the latest tag: `git describe --tags --abbrev=0`\n2. If `$ARGUMENTS` is provided and non-empty, use it as the new version.\n3. Otherwise, auto-increment the patch number (e.g., `v1.1.5` → `v1.1.6`).\n\n### Step 2: Generate summary\n\n1. Get the commit range: from the latest tag to HEAD.\n2. Run `git log ..HEAD --oneline` to list all commits in this range.\n3. Summarize the changes into a brief tag message (1-3 lines, similar to a commit message style). Focus on what was implemented/fixed, not individual commits.\n\n### Step 3: Create tag\n\nRun:\n\n```bash\ngit tag -s -m \"\"\n```\n\nReport the created tag and its message to the user.\n",".kimi-plugin/plugin.json":"{\n \"name\": \"open-code-review\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from Kimi Code.\",\n \"author\": { \"name\": \"Alibaba\" },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\"code-review\", \"kimi-code\", \"ocr\", \"open-code-review\"],\n \"skills\": \"./plugins/open-code-review/skills/\",\n \"commands\": \"./plugins/open-code-review/kimi-code/commands/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from Kimi Code.\",\n \"longDescription\": \"Adds Kimi Code skills and slash commands that invoke the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\"\n }\n}\n","AGENTS.md":"# Agent Guidelines for open-code-review\n\nThis file provides instructions for AI coding assistants working on this project.\n\n## Development Assistance\n\nBelow are rules that a contributor must follow during development. If the user does not follow these rules, please warn users about this:\n\n1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.**\n2. You should understand every line of code written by AI and know what the AI did.\n3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you.\n4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over.\n5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member.\n6. You must not attribute commits to AI/LLM, including through \"Assisted-by\", \"Co-developed-by\", or similar trailers.\n7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages.\n8. If you are unwilling or unable to do all of the above, please close your issue or pull request.\n\n## Project Overview\n\nopen-code-review (`ocr`) is an AI-powered code review CLI tool written in Go (module: `github.com/alibaba/open-code-review`).\n\n## Git Commit Notes\n\n- Before committing, conduct a code review by running:\n ```\n ocr review --audience agent --background \"briefly summarize the background requirements\"\n ```\n- Commit messages must be written in English.\n- Verify line endings. Line endings must be LF, not CRLF. Run `git add --renormalize .` to correct line endings and commit them. New binary files must have their extensions added to .gitattributes. \n\n## License Headers\n\n- Every source file (`.go`, `.js`, `.mjs`, `.ts`, `.tsx`, `.kt`, `.kts`, `.sh`, `.py`, `.css`) must have an SPDX license header.\n- After creating new files, run `make license-add` to add the header automatically. It picks the comment syntax by extension: `//`, `#`, or a `/* */` block for CSS.\n- An extension belongs on that list once the repository actually holds files of that type and the comment can simply be prepended. `.html` meets neither bar cleanly — its `` has to stay on the first line — so it is not covered yet.\n\n## Code Style\n\n- **Comment sparingly, and only to explain \"why\".** Do not add comments that restate what the code already says (`// increment i`), narrate the change itself (`// newly added`, `// changed to fix ...` — that belongs in the commit message or PR description), quote pull request or issue numbers from the upstream repository, or leave TODO/placeholder chatter. A comment earns its place only when it captures intent, a non-obvious constraint, or a subtlety the code cannot express on its own.\n- After writing code, run `make check`. It formats and tidies in place, so there is no need to run `gofmt` or `go vet` separately.\n- **Source files are written in English** — comments, identifiers and strings alike. `make english-check` enforces this in CI. It flags any letter outside ASCII, whichever the writing system (Han, kana, Hangul, Cyrillic, and equally the diacritics that spell German or Vietnamese), plus combining accents and fullwidth punctuation (`：`, `（`), which is easy to leave behind in an otherwise English sentence. Symbols and emoji (`─ → ≥ ✅`) pass, since they are not letters. Prose spelled entirely in ASCII (`Loeschen der Datei`, or a romanised transcription) takes a dictionary to spot and stays a matter for review.\n- **Translated prose has its own homes, none of them scanned.** `docs/i18n/README..md` and `docs/i18n/CONTRIBUTING..md` (`zh-CN`, `ja-JP`, `ko-KR`, `ru-RU`); the doc pages under `pages/src/content/docs//` (`en`, `zh`, `ja`, `ru`, Markdown throughout); and the UI copy tables in `pages/src/i18n/.ts`. Markdown is out of scope by extension, so translations go there freely. The i18n tables are `.ts` and would be scanned, so they are exempt by prefix instead — translated UI strings belong in those tables rather than inline in a component.\n- **Two escape hatches for the exceptional case, narrower one preferred.** Append an `allow-non-english: ` marker comment to the offending line — the right choice for a handful of lines, such as an encoding fixture or a language-switcher label, and it leaves the rest of the file protected. Only for a whole tree that is inherently non-English, add a prefix to `allowedPrefixes` in `scripts/verify-english-only.go`; that list records each exemption's reason and the removal conditions for temporary translation exemptions.\n\n## Provider Presets\n\nWhen changing built-in provider metadata or model lists in\n`internal/llm/providers.go`, run `go generate ./internal/llm` from the\nrepository root. Commit both generated files with the registry change;\ndo not edit them by hand:\n\n- `extensions/frontend/src/shared/providers.generated.ts`\n- `extensions/idea/src/main/kotlin/com/alibaba/opencodereview/idea/services/ProviderNames.generated.kt`\n\n## Testing\n\n- Run unit tests with `make test`, not `go test` directly.\n- `make test` sets `LC_ALL=C` to ensure git outputs English messages.\n- When writing or modifying code, add necessary unit tests to maintain coverage. The project enforces a 90% coverage threshold via `make coverage`.\n\n## README\n\n- When modifying README.md, always sync the changes to all localized versions:\n - docs/i18n/README.zh-CN.md\n - docs/i18n/README.ja-JP.md\n - docs/i18n/README.ko-KR.md\n - docs/i18n/README.ru-RU.md\n","CLAUDE.md":"@AGENTS.md\n","extensions/idea/README.md":"

\n English | 简体中文\n

\n\n# Open Code Review (IntelliJ IDEA Plugin)\n\nAn IntelliJ IDEA plugin built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It hosts the VS Code extension's Preact webview inside a JCEF browser and brings AI code review into the editor: start reviews from the tool window, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the tool window both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the tool window while inline comment panels render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the plugin (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the config panel.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the plugin's config panel:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- JDK 21 (used by Gradle to run the build). The Gradle wrapper is included, so no separate Gradle install is required.\n- Node.js + npm — build-time only, to bundle the webview. Not required at runtime.\n- A globally available `ocr` CLI and `git` (see \"Prerequisites\") — the plugin is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/idea\n./gradlew runIde # launch a sandbox IDE with the plugin installed\n```\n\nOpen a project with Git changes in the sandbox IDE — you'll see the Open Code Review icon in the\ntool window strip and can start a review.\n\n> After editing code: webview changes require **reopening the tool window** in the sandbox IDE;\n> host-side (Kotlin) changes require **restarting `runIde`**.\n\n### Scripts\n\n```bash\n./gradlew build # compile Kotlin + npm install + npm run build (bundles the webview)\n./gradlew test # run unit tests\n./gradlew runIde # launch a sandbox IDE with the plugin\n./gradlew buildPlugin # produce a distributable .zip (see \"Build a release package\")\n```\n\n> No Node.js / npm on PATH? Skip the frontend build with `./gradlew -PskipFrontend=true`\n> (uses the previously bundled `src/main/resources/webview/` output).\n\n### Debugging notes\n\n- **Two-way messaging**: the webview and host communicate via `postMessage` through the JCEF bridge;\n message types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start there when debugging. The bridge transport is the only file that differs from the\n VS Code extension: `frontend/src/webview/bridge.idea.ts` (vs. `bridge.vsc.ts`). webpack selects the\n correct bridge via `NormalModuleReplacementPlugin` based on the `OCR_TARGET` environment variable.\n- **CLI invocation**: all `ocr` sub-commands run via `ProcessBuilder` in\n `src/main/kotlin/com/alibaba/opencodereview/idea/services/CliService.kt`. A non-zero CLI exit code\n rejects with the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService.kt` reads `~/.opencodereview/config.json` and delegates writes\n to `ocr config set`. Webview fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `ConfigParse.kt`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\n./gradlew build # compiles Kotlin and bundles the webview into src/main/resources/webview/\n```\n\nArtifacts: the plugin jar (Kotlin host) + `src/main/resources/webview/{webview.js,configPanel.js}` (webview SPA).\n\n### Build a release package (.zip)\n\n```bash\n./gradlew buildPlugin\n```\n\nThis compiles the host, bundles the webview, and produces\n`build/distributions/open-code-review-idea-.zip` in the `extensions/idea` directory.\n\n### Install / verify locally\n\nIn IntelliJ IDEA: `Settings → Plugins → ⚙️ → Install Plugin from Disk…` → pick the generated `.zip`.\n\n> To use a locally installed IntelliJ IDEA instead of the downloaded platform, set `localIdePath`\n> in `~/.gradle/gradle.properties` (not the repo's `gradle.properties`, which is machine-independent).\n> The build falls back to the downloaded platform if the path is missing.\n\n---\n\n## Architecture\n\nIt uses the same **Monolithic WebView + Thin Host** design as the VS Code extension:\n\n- The **WebView** is a separately built Preact SPA, shared with the VS Code extension at\n `extensions/frontend/`. The only IDEA-specific file is `bridge.idea.ts`; webpack selects the\n correct bridge (`bridge.idea.ts` vs. `bridge.vsc.ts`) via `NormalModuleReplacementPlugin` based on\n the `OCR_TARGET` environment variable.\n- The **Host** layer (Kotlin / IntelliJ) is thin, handling only CLI invocation, the file system, Git\n operations, and editor comments. It hosts the webview inside JCEF.\n- The two communicate via `postMessage` through a JCEF bridge, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nextensions/\n├── frontend/ shared frontend (webview SPA + shared types)\n│ ├── src/shared/ shared types & postMessage protocol\n│ └── src/webview/ WebView SPA (Preact): views / components / store / bridge\n└── idea/\n ├── src/main/kotlin/ Host (Kotlin / IntelliJ): services / providers / jcef / messages\n └── src/main/resources/ plugin.xml / icons / bundled webview output\n```\n\n---\n\n## Compatibility\n\n- `com.intellij.modules.jcef` is declared as an **optional** dependency, so the plugin loads on both\n 2025.1 (JCEF in the core) and 2026.2 (JCEF as a separate bundled plugin).\n- The webview's `--vscode-*` CSS variables are injected from the current IntelliJ theme, so the UI\n follows Darcula / Light automatically.\n\n---\n\n## License\n\nApache-2.0\n","extensions/vscode/README.md":"

\n English | 简体中文 | 日本語 | 한국어 | Русский\n

\n\n# Open Code Review (VS Code Extension)\n\nA VS Code code-review extension built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It recreates the prototype experience with a Preact WebView and brings AI code review into the editor: start reviews from the sidebar, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the sidebar both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the sidebar while CommentThreads render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the extension (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the status bar.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the extension's config view:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- Node.js ≥ 18, with **Yarn** as the package manager (the repo ships a `yarn.lock`).\n- VS Code ≥ 1.74.\n- A globally available `ocr` CLI (see \"Prerequisites\" above) — the extension is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/vscode\nyarn install # install dependencies\nyarn watch # watch-mode dev build (recommended: rebuilds out/ on change)\n```\n\nThen open the `extensions/vscode` folder in VS Code and press **F5** to launch the\nExtension Development Host (debug config is provided in `.vscode/launch.json`). In the new\nwindow, open a project with Git changes — you'll see the Open Code Review icon in the\nactivity bar and can start a review.\n\n> After editing code: WebView changes require **reopening the sidebar** in the dev host window\n> (or running `Developer: Reload Webviews`); Extension Host changes require **restarting the\n> debug session** (the ⟳ button on the debug toolbar, or `Cmd+R` in the host window).\n\n### Scripts\n\n```bash\nyarn compile # one-off dev build (webpack development)\nyarn watch # watch-mode dev build\nyarn build # production build (webpack production; runs automatically before packaging)\nyarn test # run Jest unit tests\nyarn lint # ESLint\nyarn package # produce a distributable .vsix package (see \"Build a release package\")\n```\n\n### Debugging notes\n\n- **Two-way messaging**: the WebView and Extension Host communicate via `postMessage`; message\n types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start\n there when debugging.\n- **CLI invocation**: all `ocr` sub-commands run via `child_process.spawn` in\n `src/extension/services/CliService.ts`. `runRaw` rejects on a non-zero CLI exit code and includes\n the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService` reads `~/.opencodereview/config.json` and delegates writes to\n `ocr config set`. WebView fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `src/extension/services/configParse.ts`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\nyarn build # production build (webpack production)\n```\n\nArtifacts: `out/extension.js` (Extension Host) + `out/webview.js` (WebView SPA).\n\n### Build a release package (.vsix)\n\n```bash\nyarn package # = vsce package --no-yarn\n```\n\nThis command:\n\n1. Triggers `vscode:prepublish` → runs the `yarn build` production build;\n2. Excludes source, tests, and dev files per `.vscodeignore`;\n3. Produces `open-code-review-vscode-.vsix` in the current directory.\n\n> The packaging tool is `@vscode/vsce`, installed as a devDependency — no global install or network\n> download needed. `--no-yarn` skips vsce's default npm dependency-tree check (this project uses Yarn).\n\nThe release package contains only the runtime essentials: `package.json`, `README.md`,\n`resources/icon.svg`, `out/extension.js`, `out/webview.js`.\n\n### Install / verify locally\n\n```bash\ncode --install-extension open-code-review-vscode-.vsix\n```\n\nOr in VS Code: Extensions panel → top-right `⋯` → **Install from VSIX…** → pick the generated `.vsix` file.\n\n> To publish to the Marketplace, use `vsce publish` instead (requires a publisher account and PAT);\n> for everyday distribution the `.vsix` above is enough.\n\n---\n\n## Architecture\n\nIt uses a **Monolithic WebView + Thin Extension Host** design:\n\n- The **WebView** is a separately built Preact SPA, built from the shared frontend at\n `extensions/frontend/` (also used by the IntelliJ IDEA plugin).\n- The **Extension Host** layer is thin, handling only CLI invocation, the file system, Git operations,\n and editor comments.\n- The two communicate via `postMessage`, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nsrc/\n└── extension/ Extension Host (Node.js): services / providers / commands\n```\n\nThe WebView and shared types are built from the shared frontend at `extensions/frontend/` (also\nused by the IntelliJ IDEA plugin).\n\n---\n\n## License\n\nApache-2.0\n","plugins/open-code-review/.codex-plugin/plugin.json":"{\n \"name\": \"open-code-review-codex\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from local Codex.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"codex\",\n \"ocr\",\n \"open-code-review\"\n ],\n \"skills\": \"./skills/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from local Codex.\",\n \"longDescription\": \"Adds a Codex skill that invokes the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"category\": \"Developer Tools\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\",\n \"defaultPrompt\": [\n \"Use Open Code Review to review my current changes.\",\n \"Use Open Code Review to review this branch against main.\",\n \"Use Open Code Review to review and fix high-confidence issues.\"\n ]\n }\n}\n","plugins/open-code-review/.cursor-plugin/plugin.json":"{\n \"name\": \"open-code-review\",\n \"displayName\": \"Open Code Review\",\n \"version\": \"1.0.0\",\n \"description\": \"AI-powered code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"cursor\",\n \"ocr\",\n \"open-code-review\",\n \"ai-review\",\n \"git-diff\"\n ],\n \"category\": \"developer-tools\",\n \"tags\": [\n \"review\",\n \"quality\",\n \"automation\"\n ],\n \"skills\": \"../skills/\"\n}\n","plugins/open-code-review/README.md":"# Coding agent plugins\n\nOpen Code Review ships platform-specific integrations for Claude Code, Codex,\nCursor, Kimi Code, and QCA Forward. Choose your platform below instead of\nadapting installation instructions written for a different agent.\n\nAll integrations require Git 2.41 or later. Install the `ocr` CLI first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\nConfigure and test an OCR LLM before running a review, unless you plan to use\n[Delegation Mode](https://open-codereview.ai/docs/delegate):\n\n```bash\nocr config provider\nocr config model\nocr llm test\n```\n\n## Claude Code\n\nRun these commands inside Claude Code:\n\n```text\n/plugin marketplace add alibaba/open-code-review\n/plugin install open-code-review@open-code-review\n```\n\nThis installs the `/open-code-review:review` and\n`/open-code-review:delegate-review` slash commands. See the\n[Claude Code guide](https://open-codereview.ai/docs/claude-code) for manual\ninstallation, usage, and behavior.\n\n## Codex\n\nAdd this repository as a Codex marketplace, then start Codex:\n\n```bash\ncodex plugin marketplace add alibaba/open-code-review\ncodex\n```\n\nOpen `/plugins`, install and enable **Open Code Review**, then start a new task.\nThe plugin exposes callable review skills backed by the local `ocr` CLI. For\nexample:\n\n```text\n@Open Code Review review my current changes\n@Open Code Review review this branch against main\n@Open Code Review review and fix high-confidence issues\n```\n\n## Cursor\n\nThis repository includes a Cursor plugin manifest at\n[`.cursor-plugin/plugin.json`](.cursor-plugin/plugin.json). For a local manual\ninstallation, copy the entire `plugins/open-code-review/` directory to:\n\n```text\n~/.cursor/plugins/local/open-code-review/\n```\n\nVerify that the manifest is located at\n`~/.cursor/plugins/local/open-code-review/.cursor-plugin/plugin.json`, then\nrestart Cursor or run **Developer: Reload Window**. The plugin provides the\nportable OCR review skills from the bundled `skills/` directory.\n\nSee the [Cursor plugin documentation](https://cursor.com/docs/plugins) for\nplugin loading and management details.\n\n## Kimi Code\n\nThis repository is itself a Kimi Code plugin. The manifest lives at the\nrepository root ([`.kimi-plugin/plugin.json`](../../.kimi-plugin/plugin.json))\nbecause Kimi Code treats the repository root as the plugin root when installing\nfrom GitHub; its `skills` and `commands` paths point down into this directory.\n\nRun this inside Kimi Code:\n\n```text\n/plugins install https://github.com/alibaba/open-code-review\n```\n\nThen run `/reload` (or start a new session) to activate the plugin. It\nprovides the `/open-code-review:review` and `/open-code-review:delegate-review`\nslash commands plus the portable OCR review skills, backed by the local `ocr`\nCLI.\n\nPlugins are installed per-user and apply to every project. Manage the\ninstallation with `/plugins list`, `/plugins info open-code-review`,\n`/plugins disable open-code-review`, and `/plugins remove open-code-review`.\nSee the\n[Kimi Code plugin documentation](https://www.kimi.com/code/docs/en/kimi-code-cli/customization/plugins.html)\nfor details.\n\n## QCA Forward\n\nQCA Forward uses the host model through OCR delegation mode. Publish the\n`open-code-review-delegate` Skill, preinstall OCR in the referenced QCA\nenvironment, and create a Forward Template from the bundled example. No OCR\nLLM endpoint is required.\n\nSee the [QCA Forward integration guide](qca/README.md) and\n[template example](qca/template.example.json).\n","plugins/open-code-review/claude-code/.claude-plugin/plugin.json":"{\n \"name\": \"open-code-review\",\n \"commands\": \"./commands\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\"\n}","plugins/open-code-review/opencode/README.md":"# OpenCode integration\n\nThis integration exposes OpenCodeReview as native tools and slash commands in\n[OpenCode](https://opencode.ai/).\n\nIt registers:\n\n- `ocr_review` — review workspace changes, one commit, or a ref range and\n return structured JSON findings.\n- `ocr_health` — show the installed OCR version and test its configured LLM\n connection.\n- `/ocr-review` and `/ocr-health` — convenient prompts that invoke the tools.\n\nExisting user commands with either name are preserved.\n\n## Prerequisites\n\nInstall and configure OpenCodeReview first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\nocr config provider\nocr config model\nocr llm test\n```\n\nCheck your OpenCode version (`opencode --version` vs `opencode2 --version`)\nand install the matching dependencies below. The single plugin file\n(`open-code-review.ts`) serves both versions: V1 reads its `server`\nentrypoint, V2 reads its `id` + `setup` entrypoint\n([dual plugin form](https://opencode.ai/v2/docs/build/plugins#support-v1)).\nThe V2 API is imported as types only, so OpenCode 1.x needs just\n`@opencode-ai/plugin` at runtime, while OpenCode 2.x needs both packages.\n\n## Install globally\n\n```bash\nmkdir -p ~/.config/opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o ~/.config/opencode/plugins/open-code-review.ts\n```\n\nThen install the runtime dependencies for your version (otherwise the\nserver log shows `Cannot find package ...` and the plugin fails to load):\n\n```bash\ncd ~/.config/opencode\nnpm init -y # skip if package.json already exists\nnpm install @opencode-ai/plugin # OpenCode 1.x\nnpm install @opencode-ai/plugin @opencode/plugin@beta # OpenCode 2.x\n```\n\nRestart OpenCode after installation.\n\n## Install for one project\n\nRun this from the project root:\n\n```bash\nmkdir -p .opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o .opencode/plugins/open-code-review.ts\n```\n\nThen add the runtime dependencies for your version to the project's\n`.opencode/package.json` as above. Commit the plugin file if the\nintegration should be shared with the project.\n\n## Usage\n\nUse the registered commands:\n\n```text\n/ocr-review current workspace; focus on authentication regressions\n/ocr-review compare main to feature/auth-refresh\n/ocr-health\n```\n\nOr ask OpenCode naturally:\n\n```text\nUse ocr_review to review my current changes. The goal is to add rate limiting\nwithout changing the public API.\n```\n\nSet `preview` to `true` to inspect which files would be reviewed without making\nan LLM request.\n\nWhen the review context is too long to pass inline, write it to a Markdown file\nand set `backgroundFile` to its path; a relative path resolves against the\nrepository root. It cannot be combined with `background`.\n\n## Behavior and safety\n\n- Reviews use `--audience agent` and JSON output.\n- The process is launched with an argument array and `shell: false`.\n- Background context uses OCR's sanitised 8,000-character file input through a\n private temporary file, removed after success, failure, cancellation, or timeout.\n- Tool-driven reviews default to a 30-minute overall timeout and a 10 MiB output limit.\n- Cancelling the OpenCode tool terminates the OCR process (1.x; on 2.x\n the tool API has no abort signal, so cancellation relies on the overall\n timeout).\n- OCR credentials remain in the existing OCR configuration or environment.\n- Workspace mode includes staged, unstaged, and untracked files.\n\n## Development\n\n```bash\ncd plugins/open-code-review/opencode\nnpm install\nnpm run check\n```\n","plugins/open-code-review/qca/README.md":"# QCA Forward integration\n\nThis integration runs Open Code Review in delegation mode inside a QCA\nForward session. OCR performs deterministic file selection and rule\nresolution; the QCA host model performs the review. No OCR LLM endpoint or API\nkey is required.\n\n## Assets\n\n- [`template.example.json`](template.example.json) is a Forward Template\n example. Replace the skill and environment placeholders before publishing.\n- [`system-prompt.md`](system-prompt.md) is the canonical system prompt for the\n template.\n- [`../../../skills/open-code-review-delegate/SKILL.md`](../../../skills/open-code-review-delegate/SKILL.md)\n is the Skill package to publish and bind to the template.\n\n## Runtime requirements\n\nThe environment referenced by the template must provide:\n\n- Git 2.41 or later.\n- A compatible `ocr` binary on `PATH`.\n- A checked-out repository as the session workspace.\n\nFor production, preinstall and pin OCR in the runtime image. Installing the\nlatest NPM package during every session adds network, startup, and compatibility\nrisk.\n\n## Publish flow\n\n1. Package and publish `skills/open-code-review-delegate` as a QCA Skill.\n2. Build or select an environment with Git and OCR preinstalled.\n3. Replace `skill_open_code_review_delegate`, `env_code_review`, and\n `PIN_AT_PUBLISH_TIME` in the template example with real resource IDs and\n pinned Skill/OCR versions.\n4. Create the Forward Template and bind a repository through the Template or\n Identity configuration.\n5. Create a new session and send a workspace, range, or commit review request.\n\nTemplate updates affect new sessions only. Keep the template metadata aligned\nwith the pinned OCR, Skill, and delegation schema versions.\n\n## Supported requests\n\n```text\nReview the current workspace changes.\n```\n\n```text\nReview feature/order-refactor against main. The change must preserve order\nstate transition idempotency. Report medium-severity and higher findings.\n```\n\n```text\nReview commit abc123.\n```\n\n## Execution contract\n\nThe QCA agent must:\n\n1. Run `ocr delegate preview --format json` with the requested target.\n2. Put every `reviewable_files` entry into an explicit checklist.\n3. Run `ocr delegate rule --format json` for those files.\n4. Review bounded batches grouped by rule and diff size.\n5. Mark every file reviewed or skipped with a reason.\n6. Report findings plus total, reviewed, skipped, and coverage counts.\n\nUse `(path, status)` as the checklist identity. In workspace mode, a staged\ndeletion followed by an untracked recreation can legitimately produce two\nentries with the same path and different statuses.\n\nThe agent must not run `ocr review`, `ocr llm test`, or request OCR model\ncredentials.\n\n## Validation\n\n- `ocr delegate preview --format json` returns `schema_version: \"1\"`.\n- All previewed files are accounted for in the final response.\n- Write and Edit are disabled. Bash read-only behavior is prompt-enforced unless\n the QCA runtime applies a stricter command policy.\n- The session completes without `OCR_LLM_*` variables.\n- Workspace, branch range, and single-commit reviews all work.\n","plugins/open-code-review/skills/open-code-review-delegate/SKILL.md":"---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review-delegate/SKILL.md`. Keep both files synchronized when\nupdating OCR delegation instructions; a symlink is avoided because plugin\ninstalls may only materialize the plugin subtree.\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n","plugins/open-code-review/skills/open-code-review/SKILL.md":"---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review/SKILL.md`. Keep both files synchronized when updating\nOCR agent instructions; a symlink is avoided because plugin installs may only\nmaterialize the plugin subtree.\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n","skills/open-code-review-delegate/SKILL.md":"---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n","skills/open-code-review/SKILL.md":"---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n"},"files":{".agents/plugins/marketplace.json":"{\n \"name\": \"open-code-review\",\n \"interface\": {\n \"displayName\": \"Open Code Review\"\n },\n \"plugins\": [\n {\n \"name\": \"open-code-review-codex\",\n \"source\": {\n \"source\": \"local\",\n \"path\": \"./plugins/open-code-review\"\n },\n \"policy\": {\n \"installation\": \"AVAILABLE\",\n \"authentication\": \"ON_INSTALL\"\n },\n \"category\": \"Developer Tools\"\n }\n ]\n}\n",".claude-plugin/marketplace.json":"{\n \"name\": \"open-code-review\",\n \"owner\": {\n \"name\": \"alibaba\"\n },\n \"description\": \"AI-powered code review agent that reads Git diffs, analyzes changed files with LLM tool-use capabilities, and generates structured line-level review comments with cross-referential context awareness.\",\n \"plugins\": [\n {\n \"name\": \"open-code-review\",\n \"source\": \"./plugins/open-code-review/claude-code\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\",\n \"license\": \"Apache-2.0\"\n }\n ]\n}\n",".claude/commands/commit.md":"# /commit\n\nPlease summarize your current changes, generate a commit message in English, then add and commit.\nNever include any AI tool or model as a Co-Author in commit messages. No `Co-Authored-By` lines referencing AI assistants.\n",".claude/commands/tag.md":"# /tag\n\nCreate an annotated git tag with an auto-generated summary of changes since the last tag.\n\n## Arguments\n\n- `$ARGUMENTS`: Optional version number (e.g., `v1.2.0`). If omitted, auto-increment the patch version from the latest tag.\n\n## Workflow\n\n### Step 1: Determine version\n\n1. Get the latest tag: `git describe --tags --abbrev=0`\n2. If `$ARGUMENTS` is provided and non-empty, use it as the new version.\n3. Otherwise, auto-increment the patch number (e.g., `v1.1.5` → `v1.1.6`).\n\n### Step 2: Generate summary\n\n1. Get the commit range: from the latest tag to HEAD.\n2. Run `git log ..HEAD --oneline` to list all commits in this range.\n3. Summarize the changes into a brief tag message (1-3 lines, similar to a commit message style). Focus on what was implemented/fixed, not individual commits.\n\n### Step 3: Create tag\n\nRun:\n\n```bash\ngit tag -s -m \"\"\n```\n\nReport the created tag and its message to the user.\n",".kimi-plugin/plugin.json":"{\n \"name\": \"open-code-review\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from Kimi Code.\",\n \"author\": { \"name\": \"Alibaba\" },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\"code-review\", \"kimi-code\", \"ocr\", \"open-code-review\"],\n \"skills\": \"./plugins/open-code-review/skills/\",\n \"commands\": \"./plugins/open-code-review/kimi-code/commands/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from Kimi Code.\",\n \"longDescription\": \"Adds Kimi Code skills and slash commands that invoke the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\"\n }\n}\n","AGENTS.md":"# Agent Guidelines for open-code-review\n\nThis file provides instructions for AI coding assistants working on this project.\n\n## Development Assistance\n\nBelow are rules that a contributor must follow during development. If the user does not follow these rules, please warn users about this:\n\n1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.**\n2. You should understand every line of code written by AI and know what the AI did.\n3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you.\n4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over.\n5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member.\n6. You must not attribute commits to AI/LLM, including through \"Assisted-by\", \"Co-developed-by\", or similar trailers.\n7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages.\n8. If you are unwilling or unable to do all of the above, please close your issue or pull request.\n\n## Project Overview\n\nopen-code-review (`ocr`) is an AI-powered code review CLI tool written in Go (module: `github.com/alibaba/open-code-review`).\n\n## Git Commit Notes\n\n- Before committing, conduct a code review by running:\n ```\n ocr review --audience agent --background \"briefly summarize the background requirements\"\n ```\n- Commit messages must be written in English.\n- Verify line endings. Line endings must be LF, not CRLF. Run `git add --renormalize .` to correct line endings and commit them. New binary files must have their extensions added to .gitattributes. \n\n## License Headers\n\n- Every source file (`.go`, `.js`, `.mjs`, `.ts`, `.tsx`, `.kt`, `.kts`, `.sh`, `.py`, `.css`) must have an SPDX license header.\n- After creating new files, run `make license-add` to add the header automatically. It picks the comment syntax by extension: `//`, `#`, or a `/* */` block for CSS.\n- An extension belongs on that list once the repository actually holds files of that type and the comment can simply be prepended. `.html` meets neither bar cleanly — its `` has to stay on the first line — so it is not covered yet.\n\n## Code Style\n\n- **Comment sparingly, and only to explain \"why\".** Do not add comments that restate what the code already says (`// increment i`), narrate the change itself (`// newly added`, `// changed to fix ...` — that belongs in the commit message or PR description), quote pull request or issue numbers from the upstream repository, or leave TODO/placeholder chatter. A comment earns its place only when it captures intent, a non-obvious constraint, or a subtlety the code cannot express on its own.\n- After writing code, run `make check`. It formats and tidies in place, so there is no need to run `gofmt` or `go vet` separately.\n- **Source files are written in English** — comments, identifiers and strings alike. `make english-check` enforces this in CI. It flags any letter outside ASCII, whichever the writing system (Han, kana, Hangul, Cyrillic, and equally the diacritics that spell German or Vietnamese), plus combining accents and fullwidth punctuation (`：`, `（`), which is easy to leave behind in an otherwise English sentence. Symbols and emoji (`─ → ≥ ✅`) pass, since they are not letters. Prose spelled entirely in ASCII (`Loeschen der Datei`, or a romanised transcription) takes a dictionary to spot and stays a matter for review.\n- **Translated prose has its own homes, none of them scanned.** `docs/i18n/README..md` and `docs/i18n/CONTRIBUTING..md` (`zh-CN`, `ja-JP`, `ko-KR`, `ru-RU`); the doc pages under `pages/src/content/docs//` (`en`, `zh`, `ja`, `ru`, Markdown throughout); and the UI copy tables in `pages/src/i18n/.ts`. Markdown is out of scope by extension, so translations go there freely. The i18n tables are `.ts` and would be scanned, so they are exempt by prefix instead — translated UI strings belong in those tables rather than inline in a component.\n- **Two escape hatches for the exceptional case, narrower one preferred.** Append an `allow-non-english: ` marker comment to the offending line — the right choice for a handful of lines, such as an encoding fixture or a language-switcher label, and it leaves the rest of the file protected. Only for a whole tree that is inherently non-English, add a prefix to `allowedPrefixes` in `scripts/verify-english-only.go`; that list records each exemption's reason and the removal conditions for temporary translation exemptions.\n\n## Provider Presets\n\nWhen changing built-in provider metadata or model lists in\n`internal/llm/providers.go`, run `go generate ./internal/llm` from the\nrepository root. Commit both generated files with the registry change;\ndo not edit them by hand:\n\n- `extensions/frontend/src/shared/providers.generated.ts`\n- `extensions/idea/src/main/kotlin/com/alibaba/opencodereview/idea/services/ProviderNames.generated.kt`\n\n## Testing\n\n- Run unit tests with `make test`, not `go test` directly.\n- `make test` sets `LC_ALL=C` to ensure git outputs English messages.\n- When writing or modifying code, add necessary unit tests to maintain coverage. The project enforces a 90% coverage threshold via `make coverage`.\n\n## README\n\n- When modifying README.md, always sync the changes to all localized versions:\n - docs/i18n/README.zh-CN.md\n - docs/i18n/README.ja-JP.md\n - docs/i18n/README.ko-KR.md\n - docs/i18n/README.ru-RU.md\n","CLAUDE.md":"@AGENTS.md\n","extensions/idea/README.md":"

\n English | 简体中文\n

\n\n# Open Code Review (IntelliJ IDEA Plugin)\n\nAn IntelliJ IDEA plugin built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It hosts the VS Code extension's Preact webview inside a JCEF browser and brings AI code review into the editor: start reviews from the tool window, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the tool window both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the tool window while inline comment panels render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the plugin (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the config panel.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the plugin's config panel:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- JDK 21 (used by Gradle to run the build). The Gradle wrapper is included, so no separate Gradle install is required.\n- Node.js + npm — build-time only, to bundle the webview. Not required at runtime.\n- A globally available `ocr` CLI and `git` (see \"Prerequisites\") — the plugin is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/idea\n./gradlew runIde # launch a sandbox IDE with the plugin installed\n```\n\nOpen a project with Git changes in the sandbox IDE — you'll see the Open Code Review icon in the\ntool window strip and can start a review.\n\n> After editing code: webview changes require **reopening the tool window** in the sandbox IDE;\n> host-side (Kotlin) changes require **restarting `runIde`**.\n\n### Scripts\n\n```bash\n./gradlew build # compile Kotlin + npm install + npm run build (bundles the webview)\n./gradlew test # run unit tests\n./gradlew runIde # launch a sandbox IDE with the plugin\n./gradlew buildPlugin # produce a distributable .zip (see \"Build a release package\")\n```\n\n> No Node.js / npm on PATH? Skip the frontend build with `./gradlew -PskipFrontend=true`\n> (uses the previously bundled `src/main/resources/webview/` output).\n\n### Debugging notes\n\n- **Two-way messaging**: the webview and host communicate via `postMessage` through the JCEF bridge;\n message types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start there when debugging. The bridge transport is the only file that differs from the\n VS Code extension: `frontend/src/webview/bridge.idea.ts` (vs. `bridge.vsc.ts`). webpack selects the\n correct bridge via `NormalModuleReplacementPlugin` based on the `OCR_TARGET` environment variable.\n- **CLI invocation**: all `ocr` sub-commands run via `ProcessBuilder` in\n `src/main/kotlin/com/alibaba/opencodereview/idea/services/CliService.kt`. A non-zero CLI exit code\n rejects with the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService.kt` reads `~/.opencodereview/config.json` and delegates writes\n to `ocr config set`. Webview fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `ConfigParse.kt`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\n./gradlew build # compiles Kotlin and bundles the webview into src/main/resources/webview/\n```\n\nArtifacts: the plugin jar (Kotlin host) + `src/main/resources/webview/{webview.js,configPanel.js}` (webview SPA).\n\n### Build a release package (.zip)\n\n```bash\n./gradlew buildPlugin\n```\n\nThis compiles the host, bundles the webview, and produces\n`build/distributions/open-code-review-idea-.zip` in the `extensions/idea` directory.\n\n### Install / verify locally\n\nIn IntelliJ IDEA: `Settings → Plugins → ⚙️ → Install Plugin from Disk…` → pick the generated `.zip`.\n\n> To use a locally installed IntelliJ IDEA instead of the downloaded platform, set `localIdePath`\n> in `~/.gradle/gradle.properties` (not the repo's `gradle.properties`, which is machine-independent).\n> The build falls back to the downloaded platform if the path is missing.\n\n---\n\n## Architecture\n\nIt uses the same **Monolithic WebView + Thin Host** design as the VS Code extension:\n\n- The **WebView** is a separately built Preact SPA, shared with the VS Code extension at\n `extensions/frontend/`. The only IDEA-specific file is `bridge.idea.ts`; webpack selects the\n correct bridge (`bridge.idea.ts` vs. `bridge.vsc.ts`) via `NormalModuleReplacementPlugin` based on\n the `OCR_TARGET` environment variable.\n- The **Host** layer (Kotlin / IntelliJ) is thin, handling only CLI invocation, the file system, Git\n operations, and editor comments. It hosts the webview inside JCEF.\n- The two communicate via `postMessage` through a JCEF bridge, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nextensions/\n├── frontend/ shared frontend (webview SPA + shared types)\n│ ├── src/shared/ shared types & postMessage protocol\n│ └── src/webview/ WebView SPA (Preact): views / components / store / bridge\n└── idea/\n ├── src/main/kotlin/ Host (Kotlin / IntelliJ): services / providers / jcef / messages\n └── src/main/resources/ plugin.xml / icons / bundled webview output\n```\n\n---\n\n## Compatibility\n\n- `com.intellij.modules.jcef` is declared as an **optional** dependency, so the plugin loads on both\n 2025.1 (JCEF in the core) and 2026.2 (JCEF as a separate bundled plugin).\n- The webview's `--vscode-*` CSS variables are injected from the current IntelliJ theme, so the UI\n follows Darcula / Light automatically.\n\n---\n\n## License\n\nApache-2.0\n","extensions/vscode/README.md":"

\n English | 简体中文 | 日本語 | 한국어 | Русский\n

\n\n# Open Code Review (VS Code Extension)\n\nA VS Code code-review extension built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It recreates the prototype experience with a Preact WebView and brings AI code review into the editor: start reviews from the sidebar, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the sidebar both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the sidebar while CommentThreads render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the extension (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the status bar.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the extension's config view:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- Node.js ≥ 18, with **Yarn** as the package manager (the repo ships a `yarn.lock`).\n- VS Code ≥ 1.74.\n- A globally available `ocr` CLI (see \"Prerequisites\" above) — the extension is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/vscode\nyarn install # install dependencies\nyarn watch # watch-mode dev build (recommended: rebuilds out/ on change)\n```\n\nThen open the `extensions/vscode` folder in VS Code and press **F5** to launch the\nExtension Development Host (debug config is provided in `.vscode/launch.json`). In the new\nwindow, open a project with Git changes — you'll see the Open Code Review icon in the\nactivity bar and can start a review.\n\n> After editing code: WebView changes require **reopening the sidebar** in the dev host window\n> (or running `Developer: Reload Webviews`); Extension Host changes require **restarting the\n> debug session** (the ⟳ button on the debug toolbar, or `Cmd+R` in the host window).\n\n### Scripts\n\n```bash\nyarn compile # one-off dev build (webpack development)\nyarn watch # watch-mode dev build\nyarn build # production build (webpack production; runs automatically before packaging)\nyarn test # run Jest unit tests\nyarn lint # ESLint\nyarn package # produce a distributable .vsix package (see \"Build a release package\")\n```\n\n### Debugging notes\n\n- **Two-way messaging**: the WebView and Extension Host communicate via `postMessage`; message\n types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start\n there when debugging.\n- **CLI invocation**: all `ocr` sub-commands run via `child_process.spawn` in\n `src/extension/services/CliService.ts`. `runRaw` rejects on a non-zero CLI exit code and includes\n the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService` reads `~/.opencodereview/config.json` and delegates writes to\n `ocr config set`. WebView fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `src/extension/services/configParse.ts`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\nyarn build # production build (webpack production)\n```\n\nArtifacts: `out/extension.js` (Extension Host) + `out/webview.js` (WebView SPA).\n\n### Build a release package (.vsix)\n\n```bash\nyarn package # = vsce package --no-yarn\n```\n\nThis command:\n\n1. Triggers `vscode:prepublish` → runs the `yarn build` production build;\n2. Excludes source, tests, and dev files per `.vscodeignore`;\n3. Produces `open-code-review-vscode-.vsix` in the current directory.\n\n> The packaging tool is `@vscode/vsce`, installed as a devDependency — no global install or network\n> download needed. `--no-yarn` skips vsce's default npm dependency-tree check (this project uses Yarn).\n\nThe release package contains only the runtime essentials: `package.json`, `README.md`,\n`resources/icon.svg`, `out/extension.js`, `out/webview.js`.\n\n### Install / verify locally\n\n```bash\ncode --install-extension open-code-review-vscode-.vsix\n```\n\nOr in VS Code: Extensions panel → top-right `⋯` → **Install from VSIX…** → pick the generated `.vsix` file.\n\n> To publish to the Marketplace, use `vsce publish` instead (requires a publisher account and PAT);\n> for everyday distribution the `.vsix` above is enough.\n\n---\n\n## Architecture\n\nIt uses a **Monolithic WebView + Thin Extension Host** design:\n\n- The **WebView** is a separately built Preact SPA, built from the shared frontend at\n `extensions/frontend/` (also used by the IntelliJ IDEA plugin).\n- The **Extension Host** layer is thin, handling only CLI invocation, the file system, Git operations,\n and editor comments.\n- The two communicate via `postMessage`, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nsrc/\n└── extension/ Extension Host (Node.js): services / providers / commands\n```\n\nThe WebView and shared types are built from the shared frontend at `extensions/frontend/` (also\nused by the IntelliJ IDEA plugin).\n\n---\n\n## License\n\nApache-2.0\n","plugins/open-code-review/.codex-plugin/plugin.json":"{\n \"name\": \"open-code-review-codex\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from local Codex.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"codex\",\n \"ocr\",\n \"open-code-review\"\n ],\n \"skills\": \"./skills/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from local Codex.\",\n \"longDescription\": \"Adds a Codex skill that invokes the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"category\": \"Developer Tools\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\",\n \"defaultPrompt\": [\n \"Use Open Code Review to review my current changes.\",\n \"Use Open Code Review to review this branch against main.\",\n \"Use Open Code Review to review and fix high-confidence issues.\"\n ]\n }\n}\n","plugins/open-code-review/.cursor-plugin/plugin.json":"{\n \"name\": \"open-code-review\",\n \"displayName\": \"Open Code Review\",\n \"version\": \"1.0.0\",\n \"description\": \"AI-powered code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"cursor\",\n \"ocr\",\n \"open-code-review\",\n \"ai-review\",\n \"git-diff\"\n ],\n \"category\": \"developer-tools\",\n \"tags\": [\n \"review\",\n \"quality\",\n \"automation\"\n ],\n \"skills\": \"../skills/\"\n}\n","plugins/open-code-review/README.md":"# Coding agent plugins\n\nOpen Code Review ships platform-specific integrations for Claude Code, Codex,\nCursor, Kimi Code, and QCA Forward. Choose your platform below instead of\nadapting installation instructions written for a different agent.\n\nAll integrations require Git 2.41 or later. Install the `ocr` CLI first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\nConfigure and test an OCR LLM before running a review, unless you plan to use\n[Delegation Mode](https://open-codereview.ai/docs/delegate):\n\n```bash\nocr config provider\nocr config model\nocr llm test\n```\n\n## Claude Code\n\nRun these commands inside Claude Code:\n\n```text\n/plugin marketplace add alibaba/open-code-review\n/plugin install open-code-review@open-code-review\n```\n\nThis installs the `/open-code-review:review` and\n`/open-code-review:delegate-review` slash commands. See the\n[Claude Code guide](https://open-codereview.ai/docs/claude-code) for manual\ninstallation, usage, and behavior.\n\n## Codex\n\nAdd this repository as a Codex marketplace, then start Codex:\n\n```bash\ncodex plugin marketplace add alibaba/open-code-review\ncodex\n```\n\nOpen `/plugins`, install and enable **Open Code Review**, then start a new task.\nThe plugin exposes callable review skills backed by the local `ocr` CLI. For\nexample:\n\n```text\n@Open Code Review review my current changes\n@Open Code Review review this branch against main\n@Open Code Review review and fix high-confidence issues\n```\n\n## Cursor\n\nThis repository includes a Cursor plugin manifest at\n[`.cursor-plugin/plugin.json`](.cursor-plugin/plugin.json). For a local manual\ninstallation, copy the entire `plugins/open-code-review/` directory to:\n\n```text\n~/.cursor/plugins/local/open-code-review/\n```\n\nVerify that the manifest is located at\n`~/.cursor/plugins/local/open-code-review/.cursor-plugin/plugin.json`, then\nrestart Cursor or run **Developer: Reload Window**. The plugin provides the\nportable OCR review skills from the bundled `skills/` directory.\n\nSee the [Cursor plugin documentation](https://cursor.com/docs/plugins) for\nplugin loading and management details.\n\n## Kimi Code\n\nThis repository is itself a Kimi Code plugin. The manifest lives at the\nrepository root ([`.kimi-plugin/plugin.json`](../../.kimi-plugin/plugin.json))\nbecause Kimi Code treats the repository root as the plugin root when installing\nfrom GitHub; its `skills` and `commands` paths point down into this directory.\n\nRun this inside Kimi Code:\n\n```text\n/plugins install https://github.com/alibaba/open-code-review\n```\n\nThen run `/reload` (or start a new session) to activate the plugin. It\nprovides the `/open-code-review:review` and `/open-code-review:delegate-review`\nslash commands plus the portable OCR review skills, backed by the local `ocr`\nCLI.\n\nPlugins are installed per-user and apply to every project. Manage the\ninstallation with `/plugins list`, `/plugins info open-code-review`,\n`/plugins disable open-code-review`, and `/plugins remove open-code-review`.\nSee the\n[Kimi Code plugin documentation](https://www.kimi.com/code/docs/en/kimi-code-cli/customization/plugins.html)\nfor details.\n\n## QCA Forward\n\nQCA Forward uses the host model through OCR delegation mode. Publish the\n`open-code-review-delegate` Skill, preinstall OCR in the referenced QCA\nenvironment, and create a Forward Template from the bundled example. No OCR\nLLM endpoint is required.\n\nSee the [QCA Forward integration guide](qca/README.md) and\n[template example](qca/template.example.json).\n","plugins/open-code-review/claude-code/.claude-plugin/plugin.json":"{\n \"name\": \"open-code-review\",\n \"commands\": \"./commands\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\"\n}","plugins/open-code-review/opencode/README.md":"# OpenCode integration\n\nThis integration exposes OpenCodeReview as native tools and slash commands in\n[OpenCode](https://opencode.ai/).\n\nIt registers:\n\n- `ocr_review` — review workspace changes, one commit, or a ref range and\n return structured JSON findings.\n- `ocr_health` — show the installed OCR version and test its configured LLM\n connection.\n- `/ocr-review` and `/ocr-health` — convenient prompts that invoke the tools.\n\nExisting user commands with either name are preserved.\n\n## Prerequisites\n\nInstall and configure OpenCodeReview first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\nocr config provider\nocr config model\nocr llm test\n```\n\nCheck your OpenCode version (`opencode --version` vs `opencode2 --version`)\nand install the matching dependencies below. The single plugin file\n(`open-code-review.ts`) serves both versions: V1 reads its `server`\nentrypoint, V2 reads its `id` + `setup` entrypoint\n([dual plugin form](https://opencode.ai/v2/docs/build/plugins#support-v1)).\nThe V2 API is imported as types only, so OpenCode 1.x needs just\n`@opencode-ai/plugin` at runtime, while OpenCode 2.x needs both packages.\n\n## Install globally\n\n```bash\nmkdir -p ~/.config/opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o ~/.config/opencode/plugins/open-code-review.ts\n```\n\nThen install the runtime dependencies for your version (otherwise the\nserver log shows `Cannot find package ...` and the plugin fails to load):\n\n```bash\ncd ~/.config/opencode\nnpm init -y # skip if package.json already exists\nnpm install @opencode-ai/plugin # OpenCode 1.x\nnpm install @opencode-ai/plugin @opencode/plugin@beta # OpenCode 2.x\n```\n\nRestart OpenCode after installation.\n\n## Install for one project\n\nRun this from the project root:\n\n```bash\nmkdir -p .opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o .opencode/plugins/open-code-review.ts\n```\n\nThen add the runtime dependencies for your version to the project's\n`.opencode/package.json` as above. Commit the plugin file if the\nintegration should be shared with the project.\n\n## Usage\n\nUse the registered commands:\n\n```text\n/ocr-review current workspace; focus on authentication regressions\n/ocr-review compare main to feature/auth-refresh\n/ocr-health\n```\n\nOr ask OpenCode naturally:\n\n```text\nUse ocr_review to review my current changes. The goal is to add rate limiting\nwithout changing the public API.\n```\n\nSet `preview` to `true` to inspect which files would be reviewed without making\nan LLM request.\n\nWhen the review context is too long to pass inline, write it to a Markdown file\nand set `backgroundFile` to its path; a relative path resolves against the\nrepository root. It cannot be combined with `background`.\n\n## Behavior and safety\n\n- Reviews use `--audience agent` and JSON output.\n- The process is launched with an argument array and `shell: false`.\n- Background context uses OCR's sanitised 8,000-character file input through a\n private temporary file, removed after success, failure, cancellation, or timeout.\n- Tool-driven reviews default to a 30-minute overall timeout and a 10 MiB output limit.\n- Cancelling the OpenCode tool terminates the OCR process (1.x; on 2.x\n the tool API has no abort signal, so cancellation relies on the overall\n timeout).\n- OCR credentials remain in the existing OCR configuration or environment.\n- Workspace mode includes staged, unstaged, and untracked files.\n\n## Development\n\n```bash\ncd plugins/open-code-review/opencode\nnpm install\nnpm run check\n```\n","plugins/open-code-review/qca/README.md":"# QCA Forward integration\n\nThis integration runs Open Code Review in delegation mode inside a QCA\nForward session. OCR performs deterministic file selection and rule\nresolution; the QCA host model performs the review. No OCR LLM endpoint or API\nkey is required.\n\n## Assets\n\n- [`template.example.json`](template.example.json) is a Forward Template\n example. Replace the skill and environment placeholders before publishing.\n- [`system-prompt.md`](system-prompt.md) is the canonical system prompt for the\n template.\n- [`../../../skills/open-code-review-delegate/SKILL.md`](../../../skills/open-code-review-delegate/SKILL.md)\n is the Skill package to publish and bind to the template.\n\n## Runtime requirements\n\nThe environment referenced by the template must provide:\n\n- Git 2.41 or later.\n- A compatible `ocr` binary on `PATH`.\n- A checked-out repository as the session workspace.\n\nFor production, preinstall and pin OCR in the runtime image. Installing the\nlatest NPM package during every session adds network, startup, and compatibility\nrisk.\n\n## Publish flow\n\n1. Package and publish `skills/open-code-review-delegate` as a QCA Skill.\n2. Build or select an environment with Git and OCR preinstalled.\n3. Replace `skill_open_code_review_delegate`, `env_code_review`, and\n `PIN_AT_PUBLISH_TIME` in the template example with real resource IDs and\n pinned Skill/OCR versions.\n4. Create the Forward Template and bind a repository through the Template or\n Identity configuration.\n5. Create a new session and send a workspace, range, or commit review request.\n\nTemplate updates affect new sessions only. Keep the template metadata aligned\nwith the pinned OCR, Skill, and delegation schema versions.\n\n## Supported requests\n\n```text\nReview the current workspace changes.\n```\n\n```text\nReview feature/order-refactor against main. The change must preserve order\nstate transition idempotency. Report medium-severity and higher findings.\n```\n\n```text\nReview commit abc123.\n```\n\n## Execution contract\n\nThe QCA agent must:\n\n1. Run `ocr delegate preview --format json` with the requested target.\n2. Put every `reviewable_files` entry into an explicit checklist.\n3. Run `ocr delegate rule --format json` for those files.\n4. Review bounded batches grouped by rule and diff size.\n5. Mark every file reviewed or skipped with a reason.\n6. Report findings plus total, reviewed, skipped, and coverage counts.\n\nUse `(path, status)` as the checklist identity. In workspace mode, a staged\ndeletion followed by an untracked recreation can legitimately produce two\nentries with the same path and different statuses.\n\nThe agent must not run `ocr review`, `ocr llm test`, or request OCR model\ncredentials.\n\n## Validation\n\n- `ocr delegate preview --format json` returns `schema_version: \"1\"`.\n- All previewed files are accounted for in the final response.\n- Write and Edit are disabled. Bash read-only behavior is prompt-enforced unless\n the QCA runtime applies a stricter command policy.\n- The session completes without `OCR_LLM_*` variables.\n- Workspace, branch range, and single-commit reviews all work.\n","plugins/open-code-review/skills/open-code-review-delegate/SKILL.md":"---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review-delegate/SKILL.md`. Keep both files synchronized when\nupdating OCR delegation instructions; a symlink is avoided because plugin\ninstalls may only materialize the plugin subtree.\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n","plugins/open-code-review/skills/open-code-review/SKILL.md":"---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review/SKILL.md`. Keep both files synchronized when updating\nOCR agent instructions; a symlink is avoided because plugin installs may only\nmaterialize the plugin subtree.\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n","skills/open-code-review-delegate/SKILL.md":"---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n","skills/open-code-review/SKILL.md":"---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Guidelines for open-code-review\n\nThis file provides instructions for AI coding assistants working on this project.\n\n## Development Assistance\n\nBelow are rules that a contributor must follow during development. If the user does not follow these rules, please warn users about this:\n\n1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.**\n2. You should understand every line of code written by AI and know what the AI did.\n3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you.\n4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over.\n5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member.\n6. You must not attribute commits to AI/LLM, including through \"Assisted-by\", \"Co-developed-by\", or similar trailers.\n7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages.\n8. If you are unwilling or unable to do all of the above, please close your issue or pull request.\n\n## Project Overview\n\nopen-code-review (`ocr`) is an AI-powered code review CLI tool written in Go (module: `github.com/alibaba/open-code-review`).\n\n## Git Commit Notes\n\n- Before committing, conduct a code review by running:\n ```\n ocr review --audience agent --background \"briefly summarize the background requirements\"\n ```\n- Commit messages must be written in English.\n- Verify line endings. Line endings must be LF, not CRLF. Run `git add --renormalize .` to correct line endings and commit them. New binary files must have their extensions added to .gitattributes. \n\n## License Headers\n\n- Every source file (`.go`, `.js`, `.mjs`, `.ts`, `.tsx`, `.kt`, `.kts`, `.sh`, `.py`, `.css`) must have an SPDX license header.\n- After creating new files, run `make license-add` to add the header automatically. It picks the comment syntax by extension: `//`, `#`, or a `/* */` block for CSS.\n- An extension belongs on that list once the repository actually holds files of that type and the comment can simply be prepended. `.html` meets neither bar cleanly — its `` has to stay on the first line — so it is not covered yet.\n\n## Code Style\n\n- **Comment sparingly, and only to explain \"why\".** Do not add comments that restate what the code already says (`// increment i`), narrate the change itself (`// newly added`, `// changed to fix ...` — that belongs in the commit message or PR description), quote pull request or issue numbers from the upstream repository, or leave TODO/placeholder chatter. A comment earns its place only when it captures intent, a non-obvious constraint, or a subtlety the code cannot express on its own.\n- After writing code, run `make check`. It formats and tidies in place, so there is no need to run `gofmt` or `go vet` separately.\n- **Source files are written in English** — comments, identifiers and strings alike. `make english-check` enforces this in CI. It flags any letter outside ASCII, whichever the writing system (Han, kana, Hangul, Cyrillic, and equally the diacritics that spell German or Vietnamese), plus combining accents and fullwidth punctuation (`：`, `（`), which is easy to leave behind in an otherwise English sentence. Symbols and emoji (`─ → ≥ ✅`) pass, since they are not letters. Prose spelled entirely in ASCII (`Loeschen der Datei`, or a romanised transcription) takes a dictionary to spot and stays a matter for review.\n- **Translated prose has its own homes, none of them scanned.** `docs/i18n/README..md` and `docs/i18n/CONTRIBUTING..md` (`zh-CN`, `ja-JP`, `ko-KR`, `ru-RU`); the doc pages under `pages/src/content/docs//` (`en`, `zh`, `ja`, `ru`, Markdown throughout); and the UI copy tables in `pages/src/i18n/.ts`. Markdown is out of scope by extension, so translations go there freely. The i18n tables are `.ts` and would be scanned, so they are exempt by prefix instead — translated UI strings belong in those tables rather than inline in a component.\n- **Two escape hatches for the exceptional case, narrower one preferred.** Append an `allow-non-english: ` marker comment to the offending line — the right choice for a handful of lines, such as an encoding fixture or a language-switcher label, and it leaves the rest of the file protected. Only for a whole tree that is inherently non-English, add a prefix to `allowedPrefixes` in `scripts/verify-english-only.go`; that list records each exemption's reason and the removal conditions for temporary translation exemptions.\n\n## Provider Presets\n\nWhen changing built-in provider metadata or model lists in\n`internal/llm/providers.go`, run `go generate ./internal/llm` from the\nrepository root. Commit both generated files with the registry change;\ndo not edit them by hand:\n\n- `extensions/frontend/src/shared/providers.generated.ts`\n- `extensions/idea/src/main/kotlin/com/alibaba/opencodereview/idea/services/ProviderNames.generated.kt`\n\n## Testing\n\n- Run unit tests with `make test`, not `go test` directly.\n- `make test` sets `LC_ALL=C` to ensure git outputs English messages.\n- When writing or modifying code, add necessary unit tests to maintain coverage. The project enforces a 90% coverage threshold via `make coverage`.\n\n## README\n\n- When modifying README.md, always sync the changes to all localized versions:\n - docs/i18n/README.zh-CN.md\n - docs/i18n/README.ja-JP.md\n - docs/i18n/README.ko-KR.md\n - docs/i18n/README.ru-RU.md\n","isInternal":false,"tokens":1392,"sizeBytes":5992},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"@AGENTS.md\n","isInternal":false,"tokens":5,"sizeBytes":11},{"name":"SKILL.md","path":"plugins/open-code-review/skills/open-code-review-delegate/SKILL.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/skills/open-code-review-delegate/SKILL.md","title":"open-code-review-delegate","category":"anthropic-skill","format":"markdown","content":"---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review-delegate/SKILL.md`. Keep both files synchronized when\nupdating OCR delegation instructions; a symlink is avoided because plugin\ninstalls may only materialize the plugin subtree.\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n","frontmatter":{"name":"open-code-review-delegate","description":"Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM endpoint, this skill instructs the host agent to perform the code review itself, using OCR only for deterministic engineering: file selection and rule resolution. Use when the host agent should drive the review with its own LLM capabilities.\n","license":"Apache-2.0","compatibility":"Requires the `ocr` CLI installed (via `npm install -g @alibaba-group/open-code-review` or GitHub release binary). Does NOT require a configured LLM endpoint — delegation mode is LLM-free on the OCR side.\n","metadata":{"author":"alibaba","homepage":"https://github.com/alibaba/open-code-review","version":"1.0.0"}},"isInternal":false,"tokens":2180,"sizeBytes":9345},{"name":"SKILL.md","path":"plugins/open-code-review/skills/open-code-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/skills/open-code-review/SKILL.md","title":"open-code-review","category":"anthropic-skill","format":"markdown","content":"---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review/SKILL.md`. Keep both files synchronized when updating\nOCR agent instructions; a symlink is avoided because plugin installs may only\nmaterialize the plugin subtree.\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n","frontmatter":{"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.\n","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 supported LLM provider before first run (protocols: Anthropic, OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\n","metadata":{"author":"alibaba","homepage":"https://github.com/alibaba/open-code-review","version":"1.0.0"}},"isInternal":false,"tokens":3024,"sizeBytes":12891},{"name":"SKILL.md","path":"skills/open-code-review-delegate/SKILL.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/skills/open-code-review-delegate/SKILL.md","title":"open-code-review-delegate","category":"anthropic-skill","format":"markdown","content":"---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n","frontmatter":{"name":"open-code-review-delegate","description":"Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM endpoint, this skill instructs the host agent to perform the code review itself, using OCR only for deterministic engineering: file selection and rule resolution. Use when the host agent should drive the review with its own LLM capabilities.\n","license":"Apache-2.0","compatibility":"Requires the `ocr` CLI installed (via `npm install -g @alibaba-group/open-code-review` or GitHub release binary). Does NOT require a configured LLM endpoint — delegation mode is LLM-free on the OCR side.\n","metadata":{"author":"alibaba","homepage":"https://github.com/alibaba/open-code-review","version":"1.0.0"}},"isInternal":false,"tokens":2128,"sizeBytes":9072},{"name":"SKILL.md","path":"skills/open-code-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/skills/open-code-review/SKILL.md","title":"open-code-review","category":"anthropic-skill","format":"markdown","content":"---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n","frontmatter":{"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.\n","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 supported LLM provider before first run (protocols: Anthropic, OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\n","metadata":{"author":"alibaba","homepage":"https://github.com/alibaba/open-code-review","version":"1.0.0"}},"isInternal":false,"tokens":2975,"sizeBytes":12632},{"name":"commit.md","path":".claude/commands/commit.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/.claude/commands/commit.md","title":"Command: /commit","category":"command-prompt","format":"markdown","content":"# /commit\n\nPlease summarize your current changes, generate a commit message in English, then add and commit.\nNever include any AI tool or model as a Co-Author in commit messages. No `Co-Authored-By` lines referencing AI assistants.\n","isInternal":false,"tokens":52,"sizeBytes":232},{"name":"tag.md","path":".claude/commands/tag.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/.claude/commands/tag.md","title":"Command: /tag","category":"command-prompt","format":"markdown","content":"# /tag\n\nCreate an annotated git tag with an auto-generated summary of changes since the last tag.\n\n## Arguments\n\n- `$ARGUMENTS`: Optional version number (e.g., `v1.2.0`). If omitted, auto-increment the patch version from the latest tag.\n\n## Workflow\n\n### Step 1: Determine version\n\n1. Get the latest tag: `git describe --tags --abbrev=0`\n2. If `$ARGUMENTS` is provided and non-empty, use it as the new version.\n3. Otherwise, auto-increment the patch number (e.g., `v1.1.5` → `v1.1.6`).\n\n### Step 2: Generate summary\n\n1. Get the commit range: from the latest tag to HEAD.\n2. Run `git log ..HEAD --oneline` to list all commits in this range.\n3. Summarize the changes into a brief tag message (1-3 lines, similar to a commit message style). Focus on what was implemented/fixed, not individual commits.\n\n### Step 3: Create tag\n\nRun:\n\n```bash\ngit tag -s -m \"\"\n```\n\nReport the created tag and its message to the user.\n","isInternal":false,"tokens":262,"sizeBytes":949},{"name":"marketplace.json","path":".agents/plugins/marketplace.json","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/.agents/plugins/marketplace.json","title":"open-code-review","category":"marketplace","format":"json","content":"{\n \"name\": \"open-code-review\",\n \"interface\": {\n \"displayName\": \"Open Code Review\"\n },\n \"plugins\": [\n {\n \"name\": \"open-code-review-codex\",\n \"source\": {\n \"source\": \"local\",\n \"path\": \"./plugins/open-code-review\"\n },\n \"policy\": {\n \"installation\": \"AVAILABLE\",\n \"authentication\": \"ON_INSTALL\"\n },\n \"category\": \"Developer Tools\"\n }\n ]\n}\n","frontmatter":{"name":"open-code-review","interface":{"displayName":"Open Code Review"},"plugins":[{"name":"open-code-review-codex","source":{"source":"local","path":"./plugins/open-code-review"},"policy":{"installation":"AVAILABLE","authentication":"ON_INSTALL"},"category":"Developer Tools"}]},"isInternal":false,"tokens":104,"sizeBytes":403},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/.claude-plugin/marketplace.json","title":"open-code-review","category":"marketplace","format":"json","content":"{\n \"name\": \"open-code-review\",\n \"owner\": {\n \"name\": \"alibaba\"\n },\n \"description\": \"AI-powered code review agent that reads Git diffs, analyzes changed files with LLM tool-use capabilities, and generates structured line-level review comments with cross-referential context awareness.\",\n \"plugins\": [\n {\n \"name\": \"open-code-review\",\n \"source\": \"./plugins/open-code-review/claude-code\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\",\n \"license\": \"Apache-2.0\"\n }\n ]\n}\n","frontmatter":{"name":"open-code-review","owner":{"name":"alibaba"},"description":"AI-powered code review agent that reads Git diffs, analyzes changed files with LLM tool-use capabilities, and generates structured line-level review comments with cross-referential context awareness.","plugins":[{"name":"open-code-review","source":"./plugins/open-code-review/claude-code","description":"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.","version":"1.0.0","license":"Apache-2.0"}]},"isInternal":false,"tokens":161,"sizeBytes":682},{"name":"plugin.json","path":".kimi-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/.kimi-plugin/plugin.json","title":"open-code-review","category":"plugin-manifest","format":"json","content":"{\n \"name\": \"open-code-review\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from Kimi Code.\",\n \"author\": { \"name\": \"Alibaba\" },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\"code-review\", \"kimi-code\", \"ocr\", \"open-code-review\"],\n \"skills\": \"./plugins/open-code-review/skills/\",\n \"commands\": \"./plugins/open-code-review/kimi-code/commands/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from Kimi Code.\",\n \"longDescription\": \"Adds Kimi Code skills and slash commands that invoke the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\"\n }\n}\n","frontmatter":{"name":"open-code-review","version":"1.0.0","description":"Use Alibaba Open Code Review from Kimi Code.","author":{"name":"Alibaba"},"homepage":"https://github.com/alibaba/open-code-review","repository":"https://github.com/alibaba/open-code-review","license":"Apache-2.0","keywords":["code-review","kimi-code","ocr","open-code-review"],"skills":"./plugins/open-code-review/skills/","commands":"./plugins/open-code-review/kimi-code/commands/","interface":{"displayName":"Open Code Review","shortDescription":"Run structured code reviews from Kimi Code.","longDescription":"Adds Kimi Code skills and slash commands that invoke the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.","developerName":"Alibaba","websiteURL":"https://github.com/alibaba/open-code-review"}},"isInternal":false,"tokens":229,"sizeBytes":895},{"name":"README.md","path":"extensions/idea/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/extensions/idea/README.md","title":"idea Documentation","category":"plugin-manifest","format":"markdown","content":"

\n English | 简体中文\n

\n\n# Open Code Review (IntelliJ IDEA Plugin)\n\nAn IntelliJ IDEA plugin built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It hosts the VS Code extension's Preact webview inside a JCEF browser and brings AI code review into the editor: start reviews from the tool window, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the tool window both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the tool window while inline comment panels render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the plugin (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the config panel.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the plugin's config panel:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- JDK 21 (used by Gradle to run the build). The Gradle wrapper is included, so no separate Gradle install is required.\n- Node.js + npm — build-time only, to bundle the webview. Not required at runtime.\n- A globally available `ocr` CLI and `git` (see \"Prerequisites\") — the plugin is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/idea\n./gradlew runIde # launch a sandbox IDE with the plugin installed\n```\n\nOpen a project with Git changes in the sandbox IDE — you'll see the Open Code Review icon in the\ntool window strip and can start a review.\n\n> After editing code: webview changes require **reopening the tool window** in the sandbox IDE;\n> host-side (Kotlin) changes require **restarting `runIde`**.\n\n### Scripts\n\n```bash\n./gradlew build # compile Kotlin + npm install + npm run build (bundles the webview)\n./gradlew test # run unit tests\n./gradlew runIde # launch a sandbox IDE with the plugin\n./gradlew buildPlugin # produce a distributable .zip (see \"Build a release package\")\n```\n\n> No Node.js / npm on PATH? Skip the frontend build with `./gradlew -PskipFrontend=true`\n> (uses the previously bundled `src/main/resources/webview/` output).\n\n### Debugging notes\n\n- **Two-way messaging**: the webview and host communicate via `postMessage` through the JCEF bridge;\n message types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start there when debugging. The bridge transport is the only file that differs from the\n VS Code extension: `frontend/src/webview/bridge.idea.ts` (vs. `bridge.vsc.ts`). webpack selects the\n correct bridge via `NormalModuleReplacementPlugin` based on the `OCR_TARGET` environment variable.\n- **CLI invocation**: all `ocr` sub-commands run via `ProcessBuilder` in\n `src/main/kotlin/com/alibaba/opencodereview/idea/services/CliService.kt`. A non-zero CLI exit code\n rejects with the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService.kt` reads `~/.opencodereview/config.json` and delegates writes\n to `ocr config set`. Webview fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `ConfigParse.kt`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\n./gradlew build # compiles Kotlin and bundles the webview into src/main/resources/webview/\n```\n\nArtifacts: the plugin jar (Kotlin host) + `src/main/resources/webview/{webview.js,configPanel.js}` (webview SPA).\n\n### Build a release package (.zip)\n\n```bash\n./gradlew buildPlugin\n```\n\nThis compiles the host, bundles the webview, and produces\n`build/distributions/open-code-review-idea-.zip` in the `extensions/idea` directory.\n\n### Install / verify locally\n\nIn IntelliJ IDEA: `Settings → Plugins → ⚙️ → Install Plugin from Disk…` → pick the generated `.zip`.\n\n> To use a locally installed IntelliJ IDEA instead of the downloaded platform, set `localIdePath`\n> in `~/.gradle/gradle.properties` (not the repo's `gradle.properties`, which is machine-independent).\n> The build falls back to the downloaded platform if the path is missing.\n\n---\n\n## Architecture\n\nIt uses the same **Monolithic WebView + Thin Host** design as the VS Code extension:\n\n- The **WebView** is a separately built Preact SPA, shared with the VS Code extension at\n `extensions/frontend/`. The only IDEA-specific file is `bridge.idea.ts`; webpack selects the\n correct bridge (`bridge.idea.ts` vs. `bridge.vsc.ts`) via `NormalModuleReplacementPlugin` based on\n the `OCR_TARGET` environment variable.\n- The **Host** layer (Kotlin / IntelliJ) is thin, handling only CLI invocation, the file system, Git\n operations, and editor comments. It hosts the webview inside JCEF.\n- The two communicate via `postMessage` through a JCEF bridge, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nextensions/\n├── frontend/ shared frontend (webview SPA + shared types)\n│ ├── src/shared/ shared types & postMessage protocol\n│ └── src/webview/ WebView SPA (Preact): views / components / store / bridge\n└── idea/\n ├── src/main/kotlin/ Host (Kotlin / IntelliJ): services / providers / jcef / messages\n └── src/main/resources/ plugin.xml / icons / bundled webview output\n```\n\n---\n\n## Compatibility\n\n- `com.intellij.modules.jcef` is declared as an **optional** dependency, so the plugin loads on both\n 2025.1 (JCEF in the core) and 2026.2 (JCEF as a separate bundled plugin).\n- The webview's `--vscode-*` CSS variables are injected from the current IntelliJ theme, so the UI\n follows Darcula / Light automatically.\n\n---\n\n## License\n\nApache-2.0\n","isInternal":false,"tokens":1689,"sizeBytes":6996},{"name":"README.md","path":"extensions/vscode/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/extensions/vscode/README.md","title":"vscode Documentation","category":"plugin-manifest","format":"markdown","content":"

\n English | 简体中文 | 日本語 | 한국어 | Русский\n

\n\n# Open Code Review (VS Code Extension)\n\nA VS Code code-review extension built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It recreates the prototype experience with a Preact WebView and brings AI code review into the editor: start reviews from the sidebar, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the sidebar both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the sidebar while CommentThreads render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the extension (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the status bar.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the extension's config view:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- Node.js ≥ 18, with **Yarn** as the package manager (the repo ships a `yarn.lock`).\n- VS Code ≥ 1.74.\n- A globally available `ocr` CLI (see \"Prerequisites\" above) — the extension is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/vscode\nyarn install # install dependencies\nyarn watch # watch-mode dev build (recommended: rebuilds out/ on change)\n```\n\nThen open the `extensions/vscode` folder in VS Code and press **F5** to launch the\nExtension Development Host (debug config is provided in `.vscode/launch.json`). In the new\nwindow, open a project with Git changes — you'll see the Open Code Review icon in the\nactivity bar and can start a review.\n\n> After editing code: WebView changes require **reopening the sidebar** in the dev host window\n> (or running `Developer: Reload Webviews`); Extension Host changes require **restarting the\n> debug session** (the ⟳ button on the debug toolbar, or `Cmd+R` in the host window).\n\n### Scripts\n\n```bash\nyarn compile # one-off dev build (webpack development)\nyarn watch # watch-mode dev build\nyarn build # production build (webpack production; runs automatically before packaging)\nyarn test # run Jest unit tests\nyarn lint # ESLint\nyarn package # produce a distributable .vsix package (see \"Build a release package\")\n```\n\n### Debugging notes\n\n- **Two-way messaging**: the WebView and Extension Host communicate via `postMessage`; message\n types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start\n there when debugging.\n- **CLI invocation**: all `ocr` sub-commands run via `child_process.spawn` in\n `src/extension/services/CliService.ts`. `runRaw` rejects on a non-zero CLI exit code and includes\n the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService` reads `~/.opencodereview/config.json` and delegates writes to\n `ocr config set`. WebView fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `src/extension/services/configParse.ts`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\nyarn build # production build (webpack production)\n```\n\nArtifacts: `out/extension.js` (Extension Host) + `out/webview.js` (WebView SPA).\n\n### Build a release package (.vsix)\n\n```bash\nyarn package # = vsce package --no-yarn\n```\n\nThis command:\n\n1. Triggers `vscode:prepublish` → runs the `yarn build` production build;\n2. Excludes source, tests, and dev files per `.vscodeignore`;\n3. Produces `open-code-review-vscode-.vsix` in the current directory.\n\n> The packaging tool is `@vscode/vsce`, installed as a devDependency — no global install or network\n> download needed. `--no-yarn` skips vsce's default npm dependency-tree check (this project uses Yarn).\n\nThe release package contains only the runtime essentials: `package.json`, `README.md`,\n`resources/icon.svg`, `out/extension.js`, `out/webview.js`.\n\n### Install / verify locally\n\n```bash\ncode --install-extension open-code-review-vscode-.vsix\n```\n\nOr in VS Code: Extensions panel → top-right `⋯` → **Install from VSIX…** → pick the generated `.vsix` file.\n\n> To publish to the Marketplace, use `vsce publish` instead (requires a publisher account and PAT);\n> for everyday distribution the `.vsix` above is enough.\n\n---\n\n## Architecture\n\nIt uses a **Monolithic WebView + Thin Extension Host** design:\n\n- The **WebView** is a separately built Preact SPA, built from the shared frontend at\n `extensions/frontend/` (also used by the IntelliJ IDEA plugin).\n- The **Extension Host** layer is thin, handling only CLI invocation, the file system, Git operations,\n and editor comments.\n- The two communicate via `postMessage`, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nsrc/\n└── extension/ Extension Host (Node.js): services / providers / commands\n```\n\nThe WebView and shared types are built from the shared frontend at `extensions/frontend/` (also\nused by the IntelliJ IDEA plugin).\n\n---\n\n## License\n\nApache-2.0\n","isInternal":false,"tokens":1584,"sizeBytes":6485},{"name":"plugin.json","path":"plugins/open-code-review/.codex-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/.codex-plugin/plugin.json","title":"open-code-review-codex","category":"plugin-manifest","format":"json","content":"{\n \"name\": \"open-code-review-codex\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from local Codex.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"codex\",\n \"ocr\",\n \"open-code-review\"\n ],\n \"skills\": \"./skills/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from local Codex.\",\n \"longDescription\": \"Adds a Codex skill that invokes the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"category\": \"Developer Tools\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\",\n \"defaultPrompt\": [\n \"Use Open Code Review to review my current changes.\",\n \"Use Open Code Review to review this branch against main.\",\n \"Use Open Code Review to review and fix high-confidence issues.\"\n ]\n }\n}\n","frontmatter":{"name":"open-code-review-codex","version":"1.0.0","description":"Use Alibaba Open Code Review from local Codex.","author":{"name":"Alibaba"},"homepage":"https://github.com/alibaba/open-code-review","repository":"https://github.com/alibaba/open-code-review","license":"Apache-2.0","keywords":["code-review","codex","ocr","open-code-review"],"skills":"./skills/","interface":{"displayName":"Open Code Review","shortDescription":"Run structured code reviews from local Codex.","longDescription":"Adds a Codex skill that invokes the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.","developerName":"Alibaba","category":"Developer Tools","capabilities":["Read"],"websiteURL":"https://github.com/alibaba/open-code-review","defaultPrompt":["Use Open Code Review to review my current changes.","Use Open Code Review to review this branch against main.","Use Open Code Review to review and fix high-confidence issues."]}},"isInternal":false,"tokens":283,"sizeBytes":1121},{"name":"plugin.json","path":"plugins/open-code-review/.cursor-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/.cursor-plugin/plugin.json","title":"open-code-review","category":"plugin-manifest","format":"json","content":"{\n \"name\": \"open-code-review\",\n \"displayName\": \"Open Code Review\",\n \"version\": \"1.0.0\",\n \"description\": \"AI-powered code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"cursor\",\n \"ocr\",\n \"open-code-review\",\n \"ai-review\",\n \"git-diff\"\n ],\n \"category\": \"developer-tools\",\n \"tags\": [\n \"review\",\n \"quality\",\n \"automation\"\n ],\n \"skills\": \"../skills/\"\n}\n","frontmatter":{"name":"open-code-review","displayName":"Open Code Review","version":"1.0.0","description":"AI-powered code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.","author":{"name":"Alibaba"},"homepage":"https://github.com/alibaba/open-code-review","repository":"https://github.com/alibaba/open-code-review","license":"Apache-2.0","keywords":["code-review","cursor","ocr","open-code-review","ai-review","git-diff"],"category":"developer-tools","tags":["review","quality","automation"],"skills":"../skills/"},"isInternal":false,"tokens":197,"sizeBytes":732},{"name":"plugin.json","path":"plugins/open-code-review/claude-code/.claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/claude-code/.claude-plugin/plugin.json","title":"open-code-review","category":"plugin-manifest","format":"json","content":"{\n \"name\": \"open-code-review\",\n \"commands\": \"./commands\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\"\n}","frontmatter":{"name":"open-code-review","commands":"./commands","description":"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.","version":"1.0.0"},"isInternal":false,"tokens":68,"sizeBytes":295},{"name":"README.md","path":"plugins/open-code-review/opencode/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/opencode/README.md","title":"opencode Documentation","category":"plugin-manifest","format":"markdown","content":"# OpenCode integration\n\nThis integration exposes OpenCodeReview as native tools and slash commands in\n[OpenCode](https://opencode.ai/).\n\nIt registers:\n\n- `ocr_review` — review workspace changes, one commit, or a ref range and\n return structured JSON findings.\n- `ocr_health` — show the installed OCR version and test its configured LLM\n connection.\n- `/ocr-review` and `/ocr-health` — convenient prompts that invoke the tools.\n\nExisting user commands with either name are preserved.\n\n## Prerequisites\n\nInstall and configure OpenCodeReview first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\nocr config provider\nocr config model\nocr llm test\n```\n\nCheck your OpenCode version (`opencode --version` vs `opencode2 --version`)\nand install the matching dependencies below. The single plugin file\n(`open-code-review.ts`) serves both versions: V1 reads its `server`\nentrypoint, V2 reads its `id` + `setup` entrypoint\n([dual plugin form](https://opencode.ai/v2/docs/build/plugins#support-v1)).\nThe V2 API is imported as types only, so OpenCode 1.x needs just\n`@opencode-ai/plugin` at runtime, while OpenCode 2.x needs both packages.\n\n## Install globally\n\n```bash\nmkdir -p ~/.config/opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o ~/.config/opencode/plugins/open-code-review.ts\n```\n\nThen install the runtime dependencies for your version (otherwise the\nserver log shows `Cannot find package ...` and the plugin fails to load):\n\n```bash\ncd ~/.config/opencode\nnpm init -y # skip if package.json already exists\nnpm install @opencode-ai/plugin # OpenCode 1.x\nnpm install @opencode-ai/plugin @opencode/plugin@beta # OpenCode 2.x\n```\n\nRestart OpenCode after installation.\n\n## Install for one project\n\nRun this from the project root:\n\n```bash\nmkdir -p .opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o .opencode/plugins/open-code-review.ts\n```\n\nThen add the runtime dependencies for your version to the project's\n`.opencode/package.json` as above. Commit the plugin file if the\nintegration should be shared with the project.\n\n## Usage\n\nUse the registered commands:\n\n```text\n/ocr-review current workspace; focus on authentication regressions\n/ocr-review compare main to feature/auth-refresh\n/ocr-health\n```\n\nOr ask OpenCode naturally:\n\n```text\nUse ocr_review to review my current changes. The goal is to add rate limiting\nwithout changing the public API.\n```\n\nSet `preview` to `true` to inspect which files would be reviewed without making\nan LLM request.\n\nWhen the review context is too long to pass inline, write it to a Markdown file\nand set `backgroundFile` to its path; a relative path resolves against the\nrepository root. It cannot be combined with `background`.\n\n## Behavior and safety\n\n- Reviews use `--audience agent` and JSON output.\n- The process is launched with an argument array and `shell: false`.\n- Background context uses OCR's sanitised 8,000-character file input through a\n private temporary file, removed after success, failure, cancellation, or timeout.\n- Tool-driven reviews default to a 30-minute overall timeout and a 10 MiB output limit.\n- Cancelling the OpenCode tool terminates the OCR process (1.x; on 2.x\n the tool API has no abort signal, so cancellation relies on the overall\n timeout).\n- OCR credentials remain in the existing OCR configuration or environment.\n- Workspace mode includes staged, unstaged, and untracked files.\n\n## Development\n\n```bash\ncd plugins/open-code-review/opencode\nnpm install\nnpm run check\n```\n","isInternal":false,"tokens":848,"sizeBytes":3672},{"name":"README.md","path":"plugins/open-code-review/qca/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/qca/README.md","title":"qca Documentation","category":"plugin-manifest","format":"markdown","content":"# QCA Forward integration\n\nThis integration runs Open Code Review in delegation mode inside a QCA\nForward session. OCR performs deterministic file selection and rule\nresolution; the QCA host model performs the review. No OCR LLM endpoint or API\nkey is required.\n\n## Assets\n\n- [`template.example.json`](template.example.json) is a Forward Template\n example. Replace the skill and environment placeholders before publishing.\n- [`system-prompt.md`](system-prompt.md) is the canonical system prompt for the\n template.\n- [`../../../skills/open-code-review-delegate/SKILL.md`](../../../skills/open-code-review-delegate/SKILL.md)\n is the Skill package to publish and bind to the template.\n\n## Runtime requirements\n\nThe environment referenced by the template must provide:\n\n- Git 2.41 or later.\n- A compatible `ocr` binary on `PATH`.\n- A checked-out repository as the session workspace.\n\nFor production, preinstall and pin OCR in the runtime image. Installing the\nlatest NPM package during every session adds network, startup, and compatibility\nrisk.\n\n## Publish flow\n\n1. Package and publish `skills/open-code-review-delegate` as a QCA Skill.\n2. Build or select an environment with Git and OCR preinstalled.\n3. Replace `skill_open_code_review_delegate`, `env_code_review`, and\n `PIN_AT_PUBLISH_TIME` in the template example with real resource IDs and\n pinned Skill/OCR versions.\n4. Create the Forward Template and bind a repository through the Template or\n Identity configuration.\n5. Create a new session and send a workspace, range, or commit review request.\n\nTemplate updates affect new sessions only. Keep the template metadata aligned\nwith the pinned OCR, Skill, and delegation schema versions.\n\n## Supported requests\n\n```text\nReview the current workspace changes.\n```\n\n```text\nReview feature/order-refactor against main. The change must preserve order\nstate transition idempotency. Report medium-severity and higher findings.\n```\n\n```text\nReview commit abc123.\n```\n\n## Execution contract\n\nThe QCA agent must:\n\n1. Run `ocr delegate preview --format json` with the requested target.\n2. Put every `reviewable_files` entry into an explicit checklist.\n3. Run `ocr delegate rule --format json` for those files.\n4. Review bounded batches grouped by rule and diff size.\n5. Mark every file reviewed or skipped with a reason.\n6. Report findings plus total, reviewed, skipped, and coverage counts.\n\nUse `(path, status)` as the checklist identity. In workspace mode, a staged\ndeletion followed by an untracked recreation can legitimately produce two\nentries with the same path and different statuses.\n\nThe agent must not run `ocr review`, `ocr llm test`, or request OCR model\ncredentials.\n\n## Validation\n\n- `ocr delegate preview --format json` returns `schema_version: \"1\"`.\n- All previewed files are accounted for in the final response.\n- Write and Edit are disabled. Bash read-only behavior is prompt-enforced unless\n the QCA runtime applies a stricter command policy.\n- The session completes without `OCR_LLM_*` variables.\n- Workspace, branch range, and single-commit reviews all work.\n","isInternal":false,"tokens":667,"sizeBytes":3084},{"name":"README.md","path":"plugins/open-code-review/README.md","rawUrl":"https://raw.githubusercontent.com/alibaba/open-code-review/HEAD/plugins/open-code-review/README.md","title":"open-code-review Documentation","category":"plugin-manifest","format":"markdown","content":"# Coding agent plugins\n\nOpen Code Review ships platform-specific integrations for Claude Code, Codex,\nCursor, Kimi Code, and QCA Forward. Choose your platform below instead of\nadapting installation instructions written for a different agent.\n\nAll integrations require Git 2.41 or later. Install the `ocr` CLI first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\nConfigure and test an OCR LLM before running a review, unless you plan to use\n[Delegation Mode](https://open-codereview.ai/docs/delegate):\n\n```bash\nocr config provider\nocr config model\nocr llm test\n```\n\n## Claude Code\n\nRun these commands inside Claude Code:\n\n```text\n/plugin marketplace add alibaba/open-code-review\n/plugin install open-code-review@open-code-review\n```\n\nThis installs the `/open-code-review:review` and\n`/open-code-review:delegate-review` slash commands. See the\n[Claude Code guide](https://open-codereview.ai/docs/claude-code) for manual\ninstallation, usage, and behavior.\n\n## Codex\n\nAdd this repository as a Codex marketplace, then start Codex:\n\n```bash\ncodex plugin marketplace add alibaba/open-code-review\ncodex\n```\n\nOpen `/plugins`, install and enable **Open Code Review**, then start a new task.\nThe plugin exposes callable review skills backed by the local `ocr` CLI. For\nexample:\n\n```text\n@Open Code Review review my current changes\n@Open Code Review review this branch against main\n@Open Code Review review and fix high-confidence issues\n```\n\n## Cursor\n\nThis repository includes a Cursor plugin manifest at\n[`.cursor-plugin/plugin.json`](.cursor-plugin/plugin.json). For a local manual\ninstallation, copy the entire `plugins/open-code-review/` directory to:\n\n```text\n~/.cursor/plugins/local/open-code-review/\n```\n\nVerify that the manifest is located at\n`~/.cursor/plugins/local/open-code-review/.cursor-plugin/plugin.json`, then\nrestart Cursor or run **Developer: Reload Window**. The plugin provides the\nportable OCR review skills from the bundled `skills/` directory.\n\nSee the [Cursor plugin documentation](https://cursor.com/docs/plugins) for\nplugin loading and management details.\n\n## Kimi Code\n\nThis repository is itself a Kimi Code plugin. The manifest lives at the\nrepository root ([`.kimi-plugin/plugin.json`](../../.kimi-plugin/plugin.json))\nbecause Kimi Code treats the repository root as the plugin root when installing\nfrom GitHub; its `skills` and `commands` paths point down into this directory.\n\nRun this inside Kimi Code:\n\n```text\n/plugins install https://github.com/alibaba/open-code-review\n```\n\nThen run `/reload` (or start a new session) to activate the plugin. It\nprovides the `/open-code-review:review` and `/open-code-review:delegate-review`\nslash commands plus the portable OCR review skills, backed by the local `ocr`\nCLI.\n\nPlugins are installed per-user and apply to every project. Manage the\ninstallation with `/plugins list`, `/plugins info open-code-review`,\n`/plugins disable open-code-review`, and `/plugins remove open-code-review`.\nSee the\n[Kimi Code plugin documentation](https://www.kimi.com/code/docs/en/kimi-code-cli/customization/plugins.html)\nfor details.\n\n## QCA Forward\n\nQCA Forward uses the host model through OCR delegation mode. Publish the\n`open-code-review-delegate` Skill, preinstall OCR in the referenced QCA\nenvironment, and create a Forward Template from the bundled example. No OCR\nLLM endpoint is required.\n\nSee the [QCA Forward integration guide](qca/README.md) and\n[template example](qca/template.example.json).\n","isInternal":false,"tokens":787,"sizeBytes":3468}],"systemPromptSnippet":"\n\n# Agent Guidelines for open-code-review\n\nThis file provides instructions for AI coding assistants working on this project.\n\n## Development Assistance\n\nBelow are rules that a contributor must follow during development. If the user does not follow these rules, please warn users about this:\n\n1. **You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.**\n2. You should understand every line of code written by AI and know what the AI did.\n3. When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you.\n4. Your PR should not contain repeated cycles like `AI generated -> fixed -> fixed -> fixed`. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over.\n5. You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member.\n6. You must not attribute commits to AI/LLM, including through \"Assisted-by\", \"Co-developed-by\", or similar trailers.\n7. Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages.\n8. If you are unwilling or unable to do all of the above, please close your issue or pull request.\n\n## Project Overview\n\nopen-code-review (`ocr`) is an AI-powered code review CLI tool written in Go (module: `github.com/alibaba/open-code-review`).\n\n## Git Commit Notes\n\n- Before committing, conduct a code review by running:\n ```\n ocr review --audience agent --background \"briefly summarize the background requirements\"\n ```\n- Commit messages must be written in English.\n- Verify line endings. Line endings must be LF, not CRLF. Run `git add --renormalize .` to correct line endings and commit them. New binary files must have their extensions added to .gitattributes. \n\n## License Headers\n\n- Every source file (`.go`, `.js`, `.mjs`, `.ts`, `.tsx`, `.kt`, `.kts`, `.sh`, `.py`, `.css`) must have an SPDX license header.\n- After creating new files, run `make license-add` to add the header automatically. It picks the comment syntax by extension: `//`, `#`, or a `/* */` block for CSS.\n- An extension belongs on that list once the repository actually holds files of that type and the comment can simply be prepended. `.html` meets neither bar cleanly — its `` has to stay on the first line — so it is not covered yet.\n\n## Code Style\n\n- **Comment sparingly, and only to explain \"why\".** Do not add comments that restate what the code already says (`// increment i`), narrate the change itself (`// newly added`, `// changed to fix ...` — that belongs in the commit message or PR description), quote pull request or issue numbers from the upstream repository, or leave TODO/placeholder chatter. A comment earns its place only when it captures intent, a non-obvious constraint, or a subtlety the code cannot express on its own.\n- After writing code, run `make check`. It formats and tidies in place, so there is no need to run `gofmt` or `go vet` separately.\n- **Source files are written in English** — comments, identifiers and strings alike. `make english-check` enforces this in CI. It flags any letter outside ASCII, whichever the writing system (Han, kana, Hangul, Cyrillic, and equally the diacritics that spell German or Vietnamese), plus combining accents and fullwidth punctuation (`：`, `（`), which is easy to leave behind in an otherwise English sentence. Symbols and emoji (`─ → ≥ ✅`) pass, since they are not letters. Prose spelled entirely in ASCII (`Loeschen der Datei`, or a romanised transcription) takes a dictionary to spot and stays a matter for review.\n- **Translated prose has its own homes, none of them scanned.** `docs/i18n/README..md` and `docs/i18n/CONTRIBUTING..md` (`zh-CN`, `ja-JP`, `ko-KR`, `ru-RU`); the doc pages under `pages/src/content/docs//` (`en`, `zh`, `ja`, `ru`, Markdown throughout); and the UI copy tables in `pages/src/i18n/.ts`. Markdown is out of scope by extension, so translations go there freely. The i18n tables are `.ts` and would be scanned, so they are exempt by prefix instead — translated UI strings belong in those tables rather than inline in a component.\n- **Two escape hatches for the exceptional case, narrower one preferred.** Append an `allow-non-english: ` marker comment to the offending line — the right choice for a handful of lines, such as an encoding fixture or a language-switcher label, and it leaves the rest of the file protected. Only for a whole tree that is inherently non-English, add a prefix to `allowedPrefixes` in `scripts/verify-english-only.go`; that list records each exemption's reason and the removal conditions for temporary translation exemptions.\n\n## Provider Presets\n\nWhen changing built-in provider metadata or model lists in\n`internal/llm/providers.go`, run `go generate ./internal/llm` from the\nrepository root. Commit both generated files with the registry change;\ndo not edit them by hand:\n\n- `extensions/frontend/src/shared/providers.generated.ts`\n- `extensions/idea/src/main/kotlin/com/alibaba/opencodereview/idea/services/ProviderNames.generated.kt`\n\n## Testing\n\n- Run unit tests with `make test`, not `go test` directly.\n- `make test` sets `LC_ALL=C` to ensure git outputs English messages.\n- When writing or modifying code, add necessary unit tests to maintain coverage. The project enforces a 90% coverage threshold via `make coverage`.\n\n## README\n\n- When modifying README.md, always sync the changes to all localized versions:\n - docs/i18n/README.zh-CN.md\n - docs/i18n/README.ja-JP.md\n - docs/i18n/README.ko-KR.md\n - docs/i18n/README.ru-RU.md\n\n\n@AGENTS.md\n\n\n---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review-delegate/SKILL.md`. Keep both files synchronized when\nupdating OCR delegation instructions; a symlink is avoided because plugin\ninstalls may only materialize the plugin subtree.\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n\n---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nThis Codex plugin skill intentionally mirrors the canonical skill at\n`skills/open-code-review/SKILL.md`. Keep both files synchronized when updating\nOCR agent instructions; a symlink is avoided because plugin installs may only\nmaterialize the plugin subtree.\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n\n\n---\nname: open-code-review-delegate\ndescription: >\n Delegation mode for open-code-review (OCR). Instead of OCR calling an LLM\n endpoint, this skill instructs the host agent to perform the code review\n itself, using OCR only for deterministic engineering: file selection and\n rule resolution. Use when the host agent should drive the review with its\n own LLM capabilities.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Does NOT\n require a configured LLM endpoint — delegation mode is LLM-free on the\n OCR side.\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review — Delegation Mode\n\nA skill for performing AI code review where OCR provides deterministic engineering (file filtering, rule resolution) and the host agent performs the actual review using its own intelligence and tools.\n\n## Workflow\n\n### Step 1: Preview — Determine What to Review\n\n```bash\nocr delegate preview --format json [--from --to ] [--commit ] [--exclude ]\n```\n\nThis outputs:\n- **mode** (workspace / range / commit)\n- **from / to / commit / merge_base** — ref metadata for constructing git commands\n- **Reviewable file list** — paths, status, insertions/deletions\n- **Excluded files** — with exclusion reason\n\n**Common invocations:**\n\n| Scenario | Command |\n|----------|---------|\n| Workspace changes | `ocr delegate preview` |\n| Branch comparison | `ocr delegate preview --from main --to feature` |\n| Single commit | `ocr delegate preview -c abc123` |\n\n### Step 2: Get Rules for Files\n\n```bash\nocr delegate rule --format json ...\n```\n\nPass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.\n\n### Step 3: Get Diffs\n\nChoose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.\n\nThe diff commands disable external diff programs, text conversion, and color to produce plain patches.\n\n**Range mode** (merge_base provided in preview output):\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color .. -- \"\"\n```\n\n**Commit mode**:\n```bash\ngit --no-pager show --no-ext-diff --no-textconv --no-color -- \"\"\n```\n\n**Workspace mode**:\n```bash\n# Tracked files\ngit --no-pager diff --no-ext-diff --no-textconv --no-color HEAD -- \"\"\n# New untracked files — read directly (entire file is new code)\ncat \"\"\n```\n\nTo read context:\n\n```bash\ngit --no-pager log --no-color --oneline -- \"\"\ngit --no-pager blame --no-textconv -- \"\"\ngit --no-pager show --no-ext-diff --no-textconv --no-color \":\"\n```\n\nFor large diffs, add `--output=\"\"` to the command for the selected mode. Choose a unique absolute path outside the repository and create its parent directory. Use the same path in file-reading tool calls:\n\n```bash\ngit --no-pager diff --no-ext-diff --no-textconv --no-color --output=\"\" .. -- \"\"\n```\n\nAfter Git exits with code 0, read and review the entire file in chunks, then remove it. If Git fails or times out, retry or record `skipped` with the error. Check unexpectedly empty output against a fresh preview.\n\n### Step 4: Review Each File\n\nCreate a checklist containing every `reviewable_files` entry. For each reviewable file:\n\nUse `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.\n\n1. Get its diff (Step 3)\n2. Consult its Rule Group (from Step 2) for the review checklist\n3. Conduct a thorough review, using appropriate context tools as needed\n4. Mark the file `reviewed`, or `skipped` with a concrete reason\n\nFor large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.\n\n### Step 5: Format Output\n\nEach comment must follow this structure:\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| path | string | yes | Relative file path |\n| content | string | yes | Review comment describing the issue |\n| start_line | integer | no | Start line in the new file |\n| end_line | integer | no | End line in the new file |\n| category | enum | no | bug, security, performance, maintainability, test, style, documentation, other |\n| severity | enum | no | critical, high, medium, low |\n\n### Step 6: Classify and Report\n\nBefore reporting, verify that every previewed file is accounted for. Include `total_files`, `reviewed_files`, `skipped_files`, and `coverage_rate` in the summary. A skipped file must include its reason.\n\nGroup findings by severity:\n\n- **Critical/High**: Bugs, security issues, data loss risks — always report\n- **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context\n- **Low**: Style nits, minor suggestions — report only if clearly valuable\n\nDiscard likely false positives silently.\n\n### Step 7: Fix (Optional)\n\nIf the user requested \"review and fix\":\n- Apply High/Critical fixes directly\n- Describe Medium fixes that require manual intervention\n- Skip Low-priority items unless trivial\n\n## Sub-commands Reference\n\n| Command | Purpose |\n|---------|---------|\n| `ocr delegate preview` | Which files to review + mode/ref metadata |\n| `ocr delegate rule ` | Review rules grouped by content |\n\n## Shared Flags\n\n| Flag | Description |\n|------|-------------|\n| `--from ` | Source ref for range mode |\n| `--to ` | Target ref for range mode |\n| `-c, --commit ` | Single commit mode |\n| `--repo ` | Repository root (default: cwd) |\n| `--rule ` | Custom rule.json path |\n| `--exclude ` | Comma-separated exclude patterns |\n| `-b, --background ` | Business context |\n| `-B, --background-file ` | Business context from Markdown file (takes precedence over `-b`) |\n| `-f, --format ` | Output format; use `json` for agent integrations |\n\n## Gotchas\n\n- **No LLM needed on OCR side** — delegation mode never calls an LLM. All intelligence comes from the host agent.\n- **Rules are grouped** — Files sharing the same rule are grouped together in the output. You can pass any number of paths per call; for large changes, fetch rules per-batch as you review.\n- **Working directory matters** — `ocr delegate` operates on the Git repo at the current directory. Use `--repo /path` to override.\n- **Untracked files in workspace mode** — `preview` includes untracked files. For these, read the file directly instead of using `git diff`.\n- **Background context** — pass `--background` to `preview` when you have requirement context; it appears in the output for your reference during review.\n- **Coverage is mandatory** — every `reviewable_files` entry must end as reviewed or explicitly skipped; do not silently omit files.\n\n### Recovering Oversized Background Context\n\n`--background-file` has two independent limits. The raw file must not exceed\n1 MiB, and the sanitized content must not exceed 8000 characters. Either\ncondition aborts the command. When the command reports either limit:\n\n1. Do not silently truncate the source file.\n2. Summarize the original material while preserving its requirements,\n constraints, acceptance criteria, and other review-critical details.\n3. Retry the affected command by passing the summary as one shell-safe\n argument (for example, use a quoted/escaped argument produced by the host\n shell, or write it to a new size-bounded file and pass that file). Do not\n place untrusted summary text directly in a double-quoted shell template;\n `$()`, backticks, quotes, and variable references can still be evaluated.\n Omit the original `--background-file` so the CLI does not reload the same\n oversized file and fail again.\n4. If a faithful summary is not possible, omit the OCR background entirely and\n read the original material directly during the review.\n\n### Troubleshooting CLI Version Compatibility\n\nThe `--format` flag is available in `ocr` v1.9.0 and later. The Skill and the\ninstalled CLI can be updated independently. If a requested `preview` or `rule`\ncommand with `--format json` fails specifically with `unknown flag: --format`,\nrerun it without the flag and use text output for the rest of the delegation\nrun. Preserve the explicit mode, ref, file, and rule information from that\noutput; do not parse text output as JSON or invent missing schema fields. Do\nnot retry without the flag for any other error; report it and stop the affected\nworkflow.\n\nThe host-agent Skill may consume the equivalent text output to complete its\nreview checklist. Programmatic integrations that require `schema_version` or\nother JSON fields must require a JSON-capable CLI instead: verify with\n`ocr --version` and upgrade when necessary:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n\n---\nname: open-code-review\ndescription: >\n Performs AI-powered code review on Git changes using the `ocr` CLI from\n alibaba/open-code-review. Use when the user asks to review code, review\n a pull request, review staged/unstaged changes, review a commit, or\n compare branches for code quality issues. Produces line-level review\n comments and can automatically apply fixes when requested. With appropriate\n review rules, can detect various types of issues including bugs, security\n vulnerabilities, performance problems, and code quality concerns.\nlicense: Apache-2.0\ncompatibility: >\n Requires the `ocr` CLI installed (via `npm install -g\n @alibaba-group/open-code-review` or GitHub release binary). Requires a\n configured supported LLM provider before first run (protocols: Anthropic,\n OpenAI Chat Completions, OpenAI Responses, AWS Bedrock).\nmetadata:\n author: alibaba\n homepage: https://github.com/alibaba/open-code-review\n version: \"1.0.0\"\n---\n\n# Open Code Review\n\nA 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.\n\n## Workflow\n\n### Step 1: Gather Business Context\n\nAnalyze the review target (commits, branch, or changes) to extract concise business context. Pass this context via `--background` to improve review quality.\n\n### Step 2: Run Code Review\n\n**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.\n\nRun the OCR command with appropriate flags. **Always pass business context via `--background`** when available:\n\n```bash\nocr review --audience agent --background \"business context here\" [user-args]\n```\n\n**Argument handling:**\n\n- **Background context** (RECOMMENDED): use `--background \"context\"` or `-b \"context\"` to provide business context for better review quality\n- **Default** (no user arguments): reviews staged, unstaged, and untracked changes (workspace mode)\n- **Specific commit**: use `--commit` or `-c` to review a single commit against its parent\n- **Branch comparison**: use `--from ` and `--to ` to review diff between two refs\n- **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.\n- **Concurrency**: default concurrency is 8 file workers; reduce with `--concurrency ` if rate limits are hit\n- **Preview mode**: use `--preview` or `-p` to preview which files will be reviewed without running the LLM\n- **Output file**: use `--output ` 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`.\n- **Installation**: if `ocr` command is not found, install it by running `npm i -g @alibaba-group/open-code-review`\n\n**Common invocation patterns:**\n\n| User says | Command to run |\n|-----------|---------------|\n| \"review my changes\" / \"review the working copy\" | `ocr review --audience agent -b \"context\"` |\n| \"review this PR\" / \"review feature branch\" | `ocr review --audience agent -b \"context\" --from main --to ` |\n| \"review commit abc123\" | `ocr review --audience agent -b \"context\" --commit abc123` |\n| \"what would be reviewed?\" (dry-run) | `ocr review --preview` |\n\n**Output mode:**\n\n- Always use `--audience agent` to suppress progress UI and emit only the final summary\n- **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.\n\n**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.\n\n### Step 3: Report\n\nOCR 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.\n\n### Step 4: Fix\n\nBefore applying fixes, check whether the user requested automatic fixes:\n\n- If the user explicitly requested \"review and fix\" or similar, proceed with automatic fixes\n- If the user only requested \"review\" without fix intent, ask for permission before applying any changes\n\nWhen fixing issues and suggestions:\n\n- Focus on critical, high, and medium severity items\n- Apply fixes directly to the code when safe and well-defined\n- For complex fixes requiring manual intervention, clearly describe what needs to be done\n- Always verify fixes with the user before committing\n\n## Output Format\n\nEach comment in OCR's output contains:\n\n- `path`: File path\n- `content`: Review comment text\n- `start_line` / `end_line`: Line range (both 0 means positioning failed)\n- `category`: Issue category (bug, security, performance, maintainability, test, style, documentation, other)\n- `severity`: Issue severity (critical, high, medium, low)\n- `suggestion_code`: Optional fix suggestion\n- `existing_code`: Optional original code snippet\n- `thinking`: Optional LLM reasoning process\n\nPresent results grouped by severity using this template:\n\n```markdown\n## Code Review Results\n\n**Files reviewed**: N\n**Issues found**: X critical, Y high, Z medium\n\n### Critical\n\n- **`path/to/file.java:42`** [bug] — Brief description\n > Recommendation: How to fix\n\n### High\n\n- **`path/to/file.java:26`** [bug] — Brief description\n > Recommendation: How to fix\n\n### Medium\n\n- **`path/to/file.ts:88`** [performance] — Brief description\n > Recommendation: How to fix (if applicable)\n```\n\nIf no critical, high, or medium severity issues remain after filtering, state: \"Review complete — no critical, high, or medium issues found in N files.\"\n\n**Handling mispositioned comments:**\n\nWhen `start_line` and `end_line` are both `0`, the comment failed to locate the exact position in the file. In such cases:\n\n1. Read the comment content to understand the issue\n2. Examine the target file mentioned in the comment\n3. Identify the relevant code section based on the comment's context\n4. Apply the fix or suggestion to the correct location\n\n## Custom Review Rules\n\nIf the user wants project-specific rules, OCR resolves them in this priority order:\n\n1. `--rule ` flag (highest)\n2. `/.opencodereview/rule.json`\n3. `~/.opencodereview/rule.json`\n4. Built-in system defaults (lowest)\n\nBy 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.\n\nRule file format:\n\n```json\n{\n \"rules\": [\n {\n \"path\": \"**/*.java\",\n \"rule\": \"All new methods must validate required parameters for null\",\n \"merge_system_rule\": true\n },\n {\n \"path\": \"**/*mapper*.xml\",\n \"rule\": \"Check SQL for injection risks and missing closing tags\"\n }\n ]\n}\n```\n\nTo preview which rule applies to a file before reviewing:\n\n```bash\nocr rules check src/main/java/com/example/Foo.java\n```\n\n## Advanced Review Options\n\nBeyond the common flags above, `ocr review` exposes a few groups of controls. Run `ocr review --help` for the complete list.\n\n**Scoping**\n\n- `--exclude ''` — comma-separated gitignore-style patterns (for example `--exclude '**/generated/*,**/testdata/*'`), merged with `rule.json` excludes.\n- `--background-file ` — read review context from a Markdown file. Takes precedence over `--background`.\n\n**Output**\n\n- `--format text|json|sarif` — `text` (default) for humans; `json` for machine-readable findings; `sarif` for code-scanning integrations such as GitHub Code Scanning.\n\n**Model**\n\n- `--provider ` / `--model ` — 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).\n\n**Budget**\n\n- `--max-tokens ` — per-group prompt ceiling; defaults to the configured value or the template default (`200000`).\n- `--max-tokens-budget ` — 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)`.\n- `--no-filter` — keep all review comments and skip the LLM post-filtering call.\n\n## Gotchas\n\n- **LLM must be configured first** — `ocr review` will fail loudly if no LLM is reachable. See the Troubleshooting section below if this happens.\n- **Working directory matters** — `ocr review` operates on the Git repo at the current directory. Use `--repo /path/to/repo` to run from elsewhere.\n- **Untracked files are reviewed in workspace mode** — running bare `ocr review` includes staged, unstaged, *and* untracked changes. Stage selectively if you want narrower scope.\n- **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.\n- **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.\n- **Don't pass `--audience human`** — it streams progress UI that pollutes output. Always use `--audience agent`.\n- **Comment language follows config** — the `language` config controls review comment language, defaults to `English`, and accepts any language name (for example `English` or `中文`).\n- **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 ` and read it in full; on older CLIs, follow the **Output file** guidance above.\n- **Resume an interrupted review** — a failed or interrupted range/commit review can be continued with `ocr review --resume ` using the same `--from`/`--to` or `--commit` target (the id is printed as `retry with: --resume ` on failure, or find it with `ocr session list`). Workspace resume is not supported.\n\n## Validation\n\nAfter the review completes, verify success by checking:\n\n1. The command exited with code 0\n2. Comments were generated (or \"No comments generated\" message appears)\n3. Warnings (if any) are displayed in stderr\n\nIf errors occurred, check the stderr warnings for details about which files failed and why.\n\n## Troubleshooting\n\n**`ocr: command not found`**\n\nInstall the CLI:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\n**`unknown flag: --output`**\n\nThe 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`.\n\n**`ocr review` fails with LLM connection error**\n\nPrompt the user to configure an LLM provider.\n\nInteractive setup (recommended):\n\n```bash\nocr config provider\n```\n\nManual setup (alternative):\n\n```bash\nocr config set llm.url https://api.anthropic.com/v1/messages\nocr config set llm.auth_token \nocr config set llm.model claude-opus-4-6\nocr config set llm.use_anthropic true\n```\n\nVerify connectivity with `ocr llm test`. Stop here and ask the user to provide credentials — never invent or hardcode API keys.\n\n## References\n\n- Full docs: https://github.com/alibaba/open-code-review\n- NPM package: https://www.npmjs.com/package/@alibaba-group/open-code-review\n- Issue tracker: https://github.com/alibaba/open-code-review/issues\n\n\n# /commit\n\nPlease summarize your current changes, generate a commit message in English, then add and commit.\nNever include any AI tool or model as a Co-Author in commit messages. No `Co-Authored-By` lines referencing AI assistants.\n\n\n# /tag\n\nCreate an annotated git tag with an auto-generated summary of changes since the last tag.\n\n## Arguments\n\n- `$ARGUMENTS`: Optional version number (e.g., `v1.2.0`). If omitted, auto-increment the patch version from the latest tag.\n\n## Workflow\n\n### Step 1: Determine version\n\n1. Get the latest tag: `git describe --tags --abbrev=0`\n2. If `$ARGUMENTS` is provided and non-empty, use it as the new version.\n3. Otherwise, auto-increment the patch number (e.g., `v1.1.5` → `v1.1.6`).\n\n### Step 2: Generate summary\n\n1. Get the commit range: from the latest tag to HEAD.\n2. Run `git log ..HEAD --oneline` to list all commits in this range.\n3. Summarize the changes into a brief tag message (1-3 lines, similar to a commit message style). Focus on what was implemented/fixed, not individual commits.\n\n### Step 3: Create tag\n\nRun:\n\n```bash\ngit tag -s -m \"\"\n```\n\nReport the created tag and its message to the user.\n\n\n{\n \"name\": \"open-code-review\",\n \"interface\": {\n \"displayName\": \"Open Code Review\"\n },\n \"plugins\": [\n {\n \"name\": \"open-code-review-codex\",\n \"source\": {\n \"source\": \"local\",\n \"path\": \"./plugins/open-code-review\"\n },\n \"policy\": {\n \"installation\": \"AVAILABLE\",\n \"authentication\": \"ON_INSTALL\"\n },\n \"category\": \"Developer Tools\"\n }\n ]\n}\n\n\n{\n \"name\": \"open-code-review\",\n \"owner\": {\n \"name\": \"alibaba\"\n },\n \"description\": \"AI-powered code review agent that reads Git diffs, analyzes changed files with LLM tool-use capabilities, and generates structured line-level review comments with cross-referential context awareness.\",\n \"plugins\": [\n {\n \"name\": \"open-code-review\",\n \"source\": \"./plugins/open-code-review/claude-code\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\",\n \"license\": \"Apache-2.0\"\n }\n ]\n}\n\n\n{\n \"name\": \"open-code-review\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from Kimi Code.\",\n \"author\": { \"name\": \"Alibaba\" },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\"code-review\", \"kimi-code\", \"ocr\", \"open-code-review\"],\n \"skills\": \"./plugins/open-code-review/skills/\",\n \"commands\": \"./plugins/open-code-review/kimi-code/commands/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from Kimi Code.\",\n \"longDescription\": \"Adds Kimi Code skills and slash commands that invoke the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\"\n }\n}\n\n\n

\n English | 简体中文\n

\n\n# Open Code Review (IntelliJ IDEA Plugin)\n\nAn IntelliJ IDEA plugin built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It hosts the VS Code extension's Preact webview inside a JCEF browser and brings AI code review into the editor: start reviews from the tool window, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the tool window both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the tool window while inline comment panels render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the plugin (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the config panel.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the plugin's config panel:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- JDK 21 (used by Gradle to run the build). The Gradle wrapper is included, so no separate Gradle install is required.\n- Node.js + npm — build-time only, to bundle the webview. Not required at runtime.\n- A globally available `ocr` CLI and `git` (see \"Prerequisites\") — the plugin is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/idea\n./gradlew runIde # launch a sandbox IDE with the plugin installed\n```\n\nOpen a project with Git changes in the sandbox IDE — you'll see the Open Code Review icon in the\ntool window strip and can start a review.\n\n> After editing code: webview changes require **reopening the tool window** in the sandbox IDE;\n> host-side (Kotlin) changes require **restarting `runIde`**.\n\n### Scripts\n\n```bash\n./gradlew build # compile Kotlin + npm install + npm run build (bundles the webview)\n./gradlew test # run unit tests\n./gradlew runIde # launch a sandbox IDE with the plugin\n./gradlew buildPlugin # produce a distributable .zip (see \"Build a release package\")\n```\n\n> No Node.js / npm on PATH? Skip the frontend build with `./gradlew -PskipFrontend=true`\n> (uses the previously bundled `src/main/resources/webview/` output).\n\n### Debugging notes\n\n- **Two-way messaging**: the webview and host communicate via `postMessage` through the JCEF bridge;\n message types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start there when debugging. The bridge transport is the only file that differs from the\n VS Code extension: `frontend/src/webview/bridge.idea.ts` (vs. `bridge.vsc.ts`). webpack selects the\n correct bridge via `NormalModuleReplacementPlugin` based on the `OCR_TARGET` environment variable.\n- **CLI invocation**: all `ocr` sub-commands run via `ProcessBuilder` in\n `src/main/kotlin/com/alibaba/opencodereview/idea/services/CliService.kt`. A non-zero CLI exit code\n rejects with the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService.kt` reads `~/.opencodereview/config.json` and delegates writes\n to `ocr config set`. Webview fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `ConfigParse.kt`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\n./gradlew build # compiles Kotlin and bundles the webview into src/main/resources/webview/\n```\n\nArtifacts: the plugin jar (Kotlin host) + `src/main/resources/webview/{webview.js,configPanel.js}` (webview SPA).\n\n### Build a release package (.zip)\n\n```bash\n./gradlew buildPlugin\n```\n\nThis compiles the host, bundles the webview, and produces\n`build/distributions/open-code-review-idea-.zip` in the `extensions/idea` directory.\n\n### Install / verify locally\n\nIn IntelliJ IDEA: `Settings → Plugins → ⚙️ → Install Plugin from Disk…` → pick the generated `.zip`.\n\n> To use a locally installed IntelliJ IDEA instead of the downloaded platform, set `localIdePath`\n> in `~/.gradle/gradle.properties` (not the repo's `gradle.properties`, which is machine-independent).\n> The build falls back to the downloaded platform if the path is missing.\n\n---\n\n## Architecture\n\nIt uses the same **Monolithic WebView + Thin Host** design as the VS Code extension:\n\n- The **WebView** is a separately built Preact SPA, shared with the VS Code extension at\n `extensions/frontend/`. The only IDEA-specific file is `bridge.idea.ts`; webpack selects the\n correct bridge (`bridge.idea.ts` vs. `bridge.vsc.ts`) via `NormalModuleReplacementPlugin` based on\n the `OCR_TARGET` environment variable.\n- The **Host** layer (Kotlin / IntelliJ) is thin, handling only CLI invocation, the file system, Git\n operations, and editor comments. It hosts the webview inside JCEF.\n- The two communicate via `postMessage` through a JCEF bridge, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nextensions/\n├── frontend/ shared frontend (webview SPA + shared types)\n│ ├── src/shared/ shared types & postMessage protocol\n│ └── src/webview/ WebView SPA (Preact): views / components / store / bridge\n└── idea/\n ├── src/main/kotlin/ Host (Kotlin / IntelliJ): services / providers / jcef / messages\n └── src/main/resources/ plugin.xml / icons / bundled webview output\n```\n\n---\n\n## Compatibility\n\n- `com.intellij.modules.jcef` is declared as an **optional** dependency, so the plugin loads on both\n 2025.1 (JCEF in the core) and 2026.2 (JCEF as a separate bundled plugin).\n- The webview's `--vscode-*` CSS variables are injected from the current IntelliJ theme, so the UI\n follows Darcula / Light automatically.\n\n---\n\n## License\n\nApache-2.0\n\n\n

\n English | 简体中文 | 日本語 | 한국어 | Русский\n

\n\n# Open Code Review (VS Code Extension)\n\nA VS Code code-review extension built on the [`open-code-review`](https://www.npmjs.com/package/@alibaba-group/open-code-review) (`ocr`) CLI. It recreates the prototype experience with a Preact WebView and brings AI code review into the editor: start reviews from the sidebar, stream logs live, and apply / dismiss / flag-as-false-positive each comment inline — kept in sync with the sidebar both ways.\n\n---\n\n## Features\n\n- **Three review modes**: workspace changes, branch comparison (`--from` / `--to`), and a single commit (`--commit`).\n- **Files-to-review preview**: lists changed files from the current Git state; click a file to view its changes in the native diff view.\n- **Custom review prompt**: optionally append a `--background` hint for the current review.\n- **Streaming logs**: tail the CLI output live during review, cancel anytime.\n- **Results + two-way sync**: on completion, comment cards appear in the sidebar while CommentThreads render in the editor; apply / dismiss / false-positive actions stay in sync on both sides.\n- **Empty / cancelled / failed states**: dedicated views for no issues, user cancellation, and CLI failure (failures are retryable and surface the real error returned by the CLI).\n- **Configuration management**: view / edit the LLM provider config inside the extension (persisted via `ocr config set`).\n- **Model switching / connectivity test**: switch models and test connectivity to the LLM from the status bar.\n\n---\n\n## Prerequisites\n\n1. Install the `ocr` CLI globally:\n\n ```bash\n npm i -g @alibaba-group/open-code-review\n ```\n\n2. Configure a working LLM (endpoint, API key, model). Configure it via the CLI directly, or in the extension's config view:\n\n ```bash\n ocr config set llm.url https://api.anthropic.com/v1/messages\n ocr config set llm.auth_token sk-...\n ocr config set llm.model claude-opus-4-6\n ocr config set llm.use_anthropic true\n ```\n\n The config is written to `~/.opencodereview/config.json`.\n\n---\n\n## Development\n\n### Environment\n\n- Node.js ≥ 18, with **Yarn** as the package manager (the repo ships a `yarn.lock`).\n- VS Code ≥ 1.74.\n- A globally available `ocr` CLI (see \"Prerequisites\" above) — the extension is essentially a GUI front-end for `ocr`.\n\n### Start the dev environment\n\n```bash\ncd extensions/vscode\nyarn install # install dependencies\nyarn watch # watch-mode dev build (recommended: rebuilds out/ on change)\n```\n\nThen open the `extensions/vscode` folder in VS Code and press **F5** to launch the\nExtension Development Host (debug config is provided in `.vscode/launch.json`). In the new\nwindow, open a project with Git changes — you'll see the Open Code Review icon in the\nactivity bar and can start a review.\n\n> After editing code: WebView changes require **reopening the sidebar** in the dev host window\n> (or running `Developer: Reload Webviews`); Extension Host changes require **restarting the\n> debug session** (the ⟳ button on the debug toolbar, or `Cmd+R` in the host window).\n\n### Scripts\n\n```bash\nyarn compile # one-off dev build (webpack development)\nyarn watch # watch-mode dev build\nyarn build # production build (webpack production; runs automatically before packaging)\nyarn test # run Jest unit tests\nyarn lint # ESLint\nyarn package # produce a distributable .vsix package (see \"Build a release package\")\n```\n\n### Debugging notes\n\n- **Two-way messaging**: the WebView and Extension Host communicate via `postMessage`; message\n types live in `extensions/frontend/src/shared/messages.ts`. Both sides route through `dispatch`\n / `handle` — start\n there when debugging.\n- **CLI invocation**: all `ocr` sub-commands run via `child_process.spawn` in\n `src/extension/services/CliService.ts`. `runRaw` rejects on a non-zero CLI exit code and includes\n the `Error:` text from stderr, which helps diagnose \"review failed / connection failed\".\n- **Config read/write**: `ConfigService` reads `~/.opencodereview/config.json` and delegates writes to\n `ocr config set`. WebView fields are camelCase (e.g. `useAnthropic`) while the disk/CLI side is\n snake_case (e.g. `use_anthropic`); the conversion lives in `src/extension/services/configParse.ts`.\n\n---\n\n## Build\n\n### Compile artifacts only\n\n```bash\nyarn build # production build (webpack production)\n```\n\nArtifacts: `out/extension.js` (Extension Host) + `out/webview.js` (WebView SPA).\n\n### Build a release package (.vsix)\n\n```bash\nyarn package # = vsce package --no-yarn\n```\n\nThis command:\n\n1. Triggers `vscode:prepublish` → runs the `yarn build` production build;\n2. Excludes source, tests, and dev files per `.vscodeignore`;\n3. Produces `open-code-review-vscode-.vsix` in the current directory.\n\n> The packaging tool is `@vscode/vsce`, installed as a devDependency — no global install or network\n> download needed. `--no-yarn` skips vsce's default npm dependency-tree check (this project uses Yarn).\n\nThe release package contains only the runtime essentials: `package.json`, `README.md`,\n`resources/icon.svg`, `out/extension.js`, `out/webview.js`.\n\n### Install / verify locally\n\n```bash\ncode --install-extension open-code-review-vscode-.vsix\n```\n\nOr in VS Code: Extensions panel → top-right `⋯` → **Install from VSIX…** → pick the generated `.vsix` file.\n\n> To publish to the Marketplace, use `vsce publish` instead (requires a publisher account and PAT);\n> for everyday distribution the `.vsix` above is enough.\n\n---\n\n## Architecture\n\nIt uses a **Monolithic WebView + Thin Extension Host** design:\n\n- The **WebView** is a separately built Preact SPA, built from the shared frontend at\n `extensions/frontend/` (also used by the IntelliJ IDEA plugin).\n- The **Extension Host** layer is thin, handling only CLI invocation, the file system, Git operations,\n and editor comments.\n- The two communicate via `postMessage`, with shared TypeScript types in\n `extensions/frontend/src/shared/` for type safety.\n\n```\nsrc/\n└── extension/ Extension Host (Node.js): services / providers / commands\n```\n\nThe WebView and shared types are built from the shared frontend at `extensions/frontend/` (also\nused by the IntelliJ IDEA plugin).\n\n---\n\n## License\n\nApache-2.0\n\n\n{\n \"name\": \"open-code-review-codex\",\n \"version\": \"1.0.0\",\n \"description\": \"Use Alibaba Open Code Review from local Codex.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"codex\",\n \"ocr\",\n \"open-code-review\"\n ],\n \"skills\": \"./skills/\",\n \"interface\": {\n \"displayName\": \"Open Code Review\",\n \"shortDescription\": \"Run structured code reviews from local Codex.\",\n \"longDescription\": \"Adds a Codex skill that invokes the local Open Code Review CLI to review Git workspace changes, commits, and branch comparisons.\",\n \"developerName\": \"Alibaba\",\n \"category\": \"Developer Tools\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/alibaba/open-code-review\",\n \"defaultPrompt\": [\n \"Use Open Code Review to review my current changes.\",\n \"Use Open Code Review to review this branch against main.\",\n \"Use Open Code Review to review and fix high-confidence issues.\"\n ]\n }\n}\n\n\n{\n \"name\": \"open-code-review\",\n \"displayName\": \"Open Code Review\",\n \"version\": \"1.0.0\",\n \"description\": \"AI-powered code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"author\": {\n \"name\": \"Alibaba\"\n },\n \"homepage\": \"https://github.com/alibaba/open-code-review\",\n \"repository\": \"https://github.com/alibaba/open-code-review\",\n \"license\": \"Apache-2.0\",\n \"keywords\": [\n \"code-review\",\n \"cursor\",\n \"ocr\",\n \"open-code-review\",\n \"ai-review\",\n \"git-diff\"\n ],\n \"category\": \"developer-tools\",\n \"tags\": [\n \"review\",\n \"quality\",\n \"automation\"\n ],\n \"skills\": \"../skills/\"\n}\n\n\n{\n \"name\": \"open-code-review\",\n \"commands\": \"./commands\",\n \"description\": \"Perform AI code review on Git diffs — supports workspace changes, branch ranges, and single commits with concurrent per-file analysis, codebase search, and deep context-aware review.\",\n \"version\": \"1.0.0\"\n}\n\n\n# OpenCode integration\n\nThis integration exposes OpenCodeReview as native tools and slash commands in\n[OpenCode](https://opencode.ai/).\n\nIt registers:\n\n- `ocr_review` — review workspace changes, one commit, or a ref range and\n return structured JSON findings.\n- `ocr_health` — show the installed OCR version and test its configured LLM\n connection.\n- `/ocr-review` and `/ocr-health` — convenient prompts that invoke the tools.\n\nExisting user commands with either name are preserved.\n\n## Prerequisites\n\nInstall and configure OpenCodeReview first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\nocr config provider\nocr config model\nocr llm test\n```\n\nCheck your OpenCode version (`opencode --version` vs `opencode2 --version`)\nand install the matching dependencies below. The single plugin file\n(`open-code-review.ts`) serves both versions: V1 reads its `server`\nentrypoint, V2 reads its `id` + `setup` entrypoint\n([dual plugin form](https://opencode.ai/v2/docs/build/plugins#support-v1)).\nThe V2 API is imported as types only, so OpenCode 1.x needs just\n`@opencode-ai/plugin` at runtime, while OpenCode 2.x needs both packages.\n\n## Install globally\n\n```bash\nmkdir -p ~/.config/opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o ~/.config/opencode/plugins/open-code-review.ts\n```\n\nThen install the runtime dependencies for your version (otherwise the\nserver log shows `Cannot find package ...` and the plugin fails to load):\n\n```bash\ncd ~/.config/opencode\nnpm init -y # skip if package.json already exists\nnpm install @opencode-ai/plugin # OpenCode 1.x\nnpm install @opencode-ai/plugin @opencode/plugin@beta # OpenCode 2.x\n```\n\nRestart OpenCode after installation.\n\n## Install for one project\n\nRun this from the project root:\n\n```bash\nmkdir -p .opencode/plugins\ncurl -fsSL \\\n https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/opencode/open-code-review.ts \\\n -o .opencode/plugins/open-code-review.ts\n```\n\nThen add the runtime dependencies for your version to the project's\n`.opencode/package.json` as above. Commit the plugin file if the\nintegration should be shared with the project.\n\n## Usage\n\nUse the registered commands:\n\n```text\n/ocr-review current workspace; focus on authentication regressions\n/ocr-review compare main to feature/auth-refresh\n/ocr-health\n```\n\nOr ask OpenCode naturally:\n\n```text\nUse ocr_review to review my current changes. The goal is to add rate limiting\nwithout changing the public API.\n```\n\nSet `preview` to `true` to inspect which files would be reviewed without making\nan LLM request.\n\nWhen the review context is too long to pass inline, write it to a Markdown file\nand set `backgroundFile` to its path; a relative path resolves against the\nrepository root. It cannot be combined with `background`.\n\n## Behavior and safety\n\n- Reviews use `--audience agent` and JSON output.\n- The process is launched with an argument array and `shell: false`.\n- Background context uses OCR's sanitised 8,000-character file input through a\n private temporary file, removed after success, failure, cancellation, or timeout.\n- Tool-driven reviews default to a 30-minute overall timeout and a 10 MiB output limit.\n- Cancelling the OpenCode tool terminates the OCR process (1.x; on 2.x\n the tool API has no abort signal, so cancellation relies on the overall\n timeout).\n- OCR credentials remain in the existing OCR configuration or environment.\n- Workspace mode includes staged, unstaged, and untracked files.\n\n## Development\n\n```bash\ncd plugins/open-code-review/opencode\nnpm install\nnpm run check\n```\n\n\n# QCA Forward integration\n\nThis integration runs Open Code Review in delegation mode inside a QCA\nForward session. OCR performs deterministic file selection and rule\nresolution; the QCA host model performs the review. No OCR LLM endpoint or API\nkey is required.\n\n## Assets\n\n- [`template.example.json`](template.example.json) is a Forward Template\n example. Replace the skill and environment placeholders before publishing.\n- [`system-prompt.md`](system-prompt.md) is the canonical system prompt for the\n template.\n- [`../../../skills/open-code-review-delegate/SKILL.md`](../../../skills/open-code-review-delegate/SKILL.md)\n is the Skill package to publish and bind to the template.\n\n## Runtime requirements\n\nThe environment referenced by the template must provide:\n\n- Git 2.41 or later.\n- A compatible `ocr` binary on `PATH`.\n- A checked-out repository as the session workspace.\n\nFor production, preinstall and pin OCR in the runtime image. Installing the\nlatest NPM package during every session adds network, startup, and compatibility\nrisk.\n\n## Publish flow\n\n1. Package and publish `skills/open-code-review-delegate` as a QCA Skill.\n2. Build or select an environment with Git and OCR preinstalled.\n3. Replace `skill_open_code_review_delegate`, `env_code_review`, and\n `PIN_AT_PUBLISH_TIME` in the template example with real resource IDs and\n pinned Skill/OCR versions.\n4. Create the Forward Template and bind a repository through the Template or\n Identity configuration.\n5. Create a new session and send a workspace, range, or commit review request.\n\nTemplate updates affect new sessions only. Keep the template metadata aligned\nwith the pinned OCR, Skill, and delegation schema versions.\n\n## Supported requests\n\n```text\nReview the current workspace changes.\n```\n\n```text\nReview feature/order-refactor against main. The change must preserve order\nstate transition idempotency. Report medium-severity and higher findings.\n```\n\n```text\nReview commit abc123.\n```\n\n## Execution contract\n\nThe QCA agent must:\n\n1. Run `ocr delegate preview --format json` with the requested target.\n2. Put every `reviewable_files` entry into an explicit checklist.\n3. Run `ocr delegate rule --format json` for those files.\n4. Review bounded batches grouped by rule and diff size.\n5. Mark every file reviewed or skipped with a reason.\n6. Report findings plus total, reviewed, skipped, and coverage counts.\n\nUse `(path, status)` as the checklist identity. In workspace mode, a staged\ndeletion followed by an untracked recreation can legitimately produce two\nentries with the same path and different statuses.\n\nThe agent must not run `ocr review`, `ocr llm test`, or request OCR model\ncredentials.\n\n## Validation\n\n- `ocr delegate preview --format json` returns `schema_version: \"1\"`.\n- All previewed files are accounted for in the final response.\n- Write and Edit are disabled. Bash read-only behavior is prompt-enforced unless\n the QCA runtime applies a stricter command policy.\n- The session completes without `OCR_LLM_*` variables.\n- Workspace, branch range, and single-commit reviews all work.\n\n\n# Coding agent plugins\n\nOpen Code Review ships platform-specific integrations for Claude Code, Codex,\nCursor, Kimi Code, and QCA Forward. Choose your platform below instead of\nadapting installation instructions written for a different agent.\n\nAll integrations require Git 2.41 or later. Install the `ocr` CLI first:\n\n```bash\nnpm install -g @alibaba-group/open-code-review\n```\n\nConfigure and test an OCR LLM before running a review, unless you plan to use\n[Delegation Mode](https://open-codereview.ai/docs/delegate):\n\n```bash\nocr config provider\nocr config model\nocr llm test\n```\n\n## Claude Code\n\nRun these commands inside Claude Code:\n\n```text\n/plugin marketplace add alibaba/open-code-review\n/plugin install open-code-review@open-code-review\n```\n\nThis installs the `/open-code-review:review` and\n`/open-code-review:delegate-review` slash commands. See the\n[Claude Code guide](https://open-codereview.ai/docs/claude-code) for manual\ninstallation, usage, and behavior.\n\n## Codex\n\nAdd this repository as a Codex marketplace, then start Codex:\n\n```bash\ncodex plugin marketplace add alibaba/open-code-review\ncodex\n```\n\nOpen `/plugins`, install and enable **Open Code Review**, then start a new task.\nThe plugin exposes callable review skills backed by the local `ocr` CLI. For\nexample:\n\n```text\n@Open Code Review review my current changes\n@Open Code Review review this branch against main\n@Open Code Review review and fix high-confidence issues\n```\n\n## Cursor\n\nThis repository includes a Cursor plugin manifest at\n[`.cursor-plugin/plugin.json`](.cursor-plugin/plugin.json). For a local manual\ninstallation, copy the entire `plugins/open-code-review/` directory to:\n\n```text\n~/.cursor/plugins/local/open-code-review/\n```\n\nVerify that the manifest is located at\n`~/.cursor/plugins/local/open-code-review/.cursor-plugin/plugin.json`, then\nrestart Cursor or run **Developer: Reload Window**. The plugin provides the\nportable OCR review skills from the bundled `skills/` directory.\n\nSee the [Cursor plugin documentation](https://cursor.com/docs/plugins) for\nplugin loading and management details.\n\n## Kimi Code\n\nThis repository is itself a Kimi Code plugin. The manifest lives at the\nrepository root ([`.kimi-plugin/plugin.json`](../../.kimi-plugin/plugin.json))\nbecause Kimi Code treats the repository root as the plugin root when installing\nfrom GitHub; its `skills` and `commands` paths point down into this directory.\n\nRun this inside Kimi Code:\n\n```text\n/plugins install https://github.com/alibaba/open-code-review\n```\n\nThen run `/reload` (or start a new session) to activate the plugin. It\nprovides the `/open-code-review:review` and `/open-code-review:delegate-review`\nslash commands plus the portable OCR review skills, backed by the local `ocr`\nCLI.\n\nPlugins are installed per-user and apply to every project. Manage the\ninstallation with `/plugins list`, `/plugins info open-code-review`,\n`/plugins disable open-code-review`, and `/plugins remove open-code-review`.\nSee the\n[Kimi Code plugin documentation](https://www.kimi.com/code/docs/en/kimi-code-cli/customization/plugins.html)\nfor details.\n\n## QCA Forward\n\nQCA Forward uses the host model through OCR delegation mode. Publish the\n`open-code-review-delegate` Skill, preinstall OCR in the referenced QCA\nenvironment, and create a Forward Template from the bundled example. No OCR\nLLM endpoint is required.\n\nSee the [QCA Forward integration guide](qca/README.md) and\n[template example](qca/template.example.json).\n"}