OCR rules tell reviewers what to focus onsemantic risks, and are not a substitute for running lint, compilation, or tests. Only modify .opencodereview/rule.jsonwhen the user requests a change to project review strategy; ordinary code review only reads and explains existing rules.
When to use, scope, and permissions
- First look at the current target repository rules, global rules, and explicit
--ruleparameters; verify the actual priority according to the current OCR version. Do not assume fields are consistent across all versions. - Before changing project files, confirm user intent and existing modifications, and preserve unknown fields and manual comment strategy. JSON does not support standard comments; do not rewrite the entire file just to change one item.
- Rules may affect the OCR-managed model context and may also change the authorization configuration summary of the pre-commit plugin. After rule changes, old reports become invalid; first return to the harness to prepare again, and do not secretly reuse old authorization.
- Do not install/upgrade OCR, and do not trial-run a real model;
ocr rules check <path>is rule matching detection and does not prove review quality.
Workflow / Workflow
Step 1 — Define testable rules
Rewrite requirements as objects, paths, risks, counterexamples, and exclusions. For example, "review order idempotency" is better than "check all code quality."
Step 2 — Check priority and scope
Check the existing rule matching order, and determine whether to replace or merge with default rules; use the narrowest sufficient path pattern, and prepare representative files that should match and should not match.
Step 3 — Modify and verify
After modification, verify the JSON syntax, then run ocr rules check; record actual matches, rule sources, merge status, and CLI version. If the CLI does not support this command, do not claim it has been verified based on string matching.
Step 4 — Safety and delivery
Exclude rule content that executes unsafe commands, leaks credentials, or exceeds user consent; deliver the diff, matching evidence, and unverified boundaries. A real OCR review requires separate authorization.
For syntax and matching examples, see Rule Examples and Pitfalls。
Not applicable
When executable format/static gates are needed, hand off to CodeGuard; when requirements acceptance or mandatory release strategy is needed, hand off to FlowGuard; when you only want to review once without changing team strategy, use the official open-code-review / open-code-review-delegate。
Gotchas / Common Pitfalls
- If the first matching rule replaces a built-in rule, system checks may be unexpectedly lost; verify merging according to the actual priority.
rules checkproves a match, not that the model actually found a defect.- Broad paths increase noise and cost; narrow them to business boundaries and then verify approximate paths.
- After rule changes, the configuration summary of old reports is no longer valid; return to the harness to prepare again before committing.