Review rules

Reviewers combine three layers of guidance.

Built-in rulesCopy Anchor Link

Every review includes general correctness rules (logic errors, broken contracts, hidden failures, resource and concurrency bugs, data integrity, security defects visible in the change). Language rules are added for the files in a bundle:

Each reviewer prompt also lists what it must not flag: style, formatting, speculation without a reachable input, missing tests or docs, refactoring ideas, and issues in code the change does not touch.

AGENTS.mdCopy Anchor Link

If the repository has an AGENTS.md at its root, ocra passes it to reviewers as repository guidelines. It is read at the revision under review and truncated at 20,000 characters. Use it for conventions a reviewer should enforce: architecture boundaries, error-handling policy, forbidden APIs.

.ocra/rules.jsonCopy Anchor Link

Path-scoped rules apply only when a bundle contains a matching file:

{
  "rules": [
    {
      "path": "services/billing/**",
      "rule": "Every write must carry an idempotency key. Flag handlers that retry without one."
    },
    {
      "path": ["**/*.sql", "db/migrations/**"],
      "rule": "Migrations must be backward compatible with the previous release."
    }
  ]
}

• path: one glob or a list of globs.
• rule: free text given to the reviewer.

An invalid rules.json stops the run with a clear error rather than being ignored.

Rules from pluginsCopy Anchor Link

Plugins can contribute rules too, for example a shared company rule pack. See Plugins.