/open-code-review-delegate

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.
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.
metadata:
  author: alibaba
  homepage: https://github.com/alibaba/open-code-review
  version: "1.0.0"

Open Code Review — Delegation Mode

A 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.

Workflow

Step 1: Preview — Determine What to Review

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

This outputs:

• **mode** (workspace / range / commit)
• **from / to / commit / merge_base** — ref metadata for constructing git commands
• **Reviewable file list** — paths, status, insertions/deletions
• **Excluded files** — with exclusion reason

**Common invocations:**

| Scenario | Command | |----------|---------| | Workspace changes | `ocr delegate preview` | | Branch comparison | `ocr delegate preview --from main --to feature` | | Single commit | `ocr delegate preview -c abc123` |

Step 2: Get Rules for Files

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

Pass the reviewable file paths from Step 1. Output is grouped by rule content — files sharing the same rule appear under one group, avoiding repetition.

Step 3: Get Diffs

Choose the diff command using the mode and refs from Step 1. Use `git --no-pager` for every Git call during the review.

The diff commands disable external diff programs, text conversion, and color to produce plain patches.

**Range mode** (merge_base provided in preview output):

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

**Commit mode**:

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

**Workspace mode**:

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

To read context:

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

For large diffs, add `--output="<absolute-diff-file>"` 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:

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

After 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.

Step 4: Review Each File

Create a checklist containing every `reviewable_files` entry. For each reviewable file:

Use `(path, status)` as the checklist identity. Workspace mode can report the same path twice when a staged deletion is followed by an untracked recreation.

1. Get its diff (Step 3) 2. Consult its Rule Group (from Step 2) for the review checklist 3. Conduct a thorough review, using appropriate context tools as needed 4. Mark the file `reviewed`, or `skipped` with a concrete reason

For large changes, review in bounded batches grouped by shared rules and diff size. Do not stop after finding the first high-severity issue.

Step 5: Format Output

Each comment must follow this structure:

| Field | Type | Required | Description | |-------|------|----------|-------------| | path | string | yes | Relative file path | | content | string | yes | Review comment describing the issue | | start_line | integer | no | Start line in the new file | | end_line | integer | no | End line in the new file | | category | enum | no | bug, security, performance, maintainability, test, style, documentation, other | | severity | enum | no | critical, high, medium, low |

Step 6: Classify and Report

Before 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.

Group findings by severity:

• **Critical/High**: Bugs, security issues, data loss risks — always report
• **Medium**: Performance concerns, error handling gaps, maintainability issues — report with context
• **Low**: Style nits, minor suggestions — report only if clearly valuable

Discard likely false positives silently.

Step 7: Fix (Optional)

If the user requested "review and fix":

• Apply High/Critical fixes directly
• Describe Medium fixes that require manual intervention
• Skip Low-priority items unless trivial

Sub-commands Reference

| Command | Purpose | |---------|---------| | `ocr delegate preview` | Which files to review + mode/ref metadata | | `ocr delegate rule <path...>` | Review rules grouped by content |

Shared Flags

| Flag | Description | |------|-------------| | `--from <ref>` | Source ref for range mode | | `--to <ref>` | Target ref for range mode | | `-c, --commit <hash>` | Single commit mode | | `--repo <path>` | Repository root (default: cwd) | | `--rule <path>` | Custom rule.json path | | `--exclude <patterns>` | Comma-separated exclude patterns | | `-b, --background <text>` | Business context | | `-B, --background-file <path>` |