AI code review that follows your team's rules: what each tool actually ingests

"Follows our coding standards" is the phrase teams use when they mean "does not post the same generic nit for the fourth time." It sounds like one feature. It is at least three, and they fail in different ways.

The mechanisms are: a rule file the tool reads and treats as review criteria, a per-path instruction that scopes guidance to a directory, and an enforcement rule with a pass or fail attached. A tool can ship one of these and call the result "custom standards." Whether that is enough depends on what your team actually needs, and whether it runs on the edition you are on.

That last part matters more than the feature list. On GitLab Self-Managed, Azure DevOps Server and Bitbucket Data Center, hosted rule ingestion is the first thing to disappear.

Three mechanisms that get called "your standards"

An ingested rule file is the lowest-effort option. You already have a CLAUDE.md, an AGENTS.md, a .cursorrules, or a docs/coding-standards/ folder in the repo. The reviewer scans for those files and uses their content as review criteria. The upside is that the standards document already exists and both humans and coding agents read it. The downside is that the file is guidance, not a check. The reviewer interprets it, and interpretation is inconsistent across runs.

A per-path instruction is a mapping from a glob to free text. You tell the reviewer that anything under src/controllers/** should be checked for auth, input validation, and direct database calls that bypass the ORM. This is more precise than a global guideline file because the guidance only applies where it belongs, which is the difference between useful and noisy in a monorepo.

An enforcement rule with a verdict is the strictest option. The rule has a severity, a path scope, and it either fires or it does not. This is what teams reach for when the requirement is "the reviewer must block this," and it is the mechanism least likely to be available on every plan. Severity levels and the ability to gate a merge are where vendors draw plan lines.

The practical consequence: if your team's real complaint is that the reviewer misses your conventions, a rule file and per-path instructions handle it. If the complaint is that the reviewer is inconsistent and you need a hard stop, only the third mechanism does that, and it may sit behind a paid tier or a licensed self-hosted deployment.

What CodeRabbit ingests, and where it stops

CodeRabbit detects guideline files automatically and applies them as review criteria with no configuration. The code guidelines docs list the patterns: **/AGENTS.md, **/.cursorrules, .github/copilot-instructions.md, .github/instructions/*.instructions.md, **/CLAUDE.md, **/.windsurfrules, **/.clinerules/*, **/.rules/*, among others. Matching is case-sensitive, so a file named claude.md is not picked up.

Scoping is directory-based. A CLAUDE.md at the repo root applies to everything; src/backend/.cursorrules applies only under src/backend/. When directory placement does not match the files a guideline should govern, you switch to the object form of filePatterns with an explicit applyTo glob. That is the per-path mechanism, and it is the one that makes a monorepo workable.

Guidelines can also come from another repository, written as repo:path or owner/repo:path. Here the edition split shows up. On GitHub the source and reviewed repos must share an organization, on GitLab they must share a top-level group, and Bitbucket Cloud must share a workspace. The docs mark the Bitbucket entry Cloud Only. Cross-repo guideline reuse is not a path available on Bitbucket Data Center.

One trap worth calling out because it is easy to hit: adding a guideline filename like CLAUDE.md to path_instructions does not use it as a guideline. It tells the reviewer to review that file as changed code. Use filePatterns.

Qodo's governance layer

Qodo routes rule and standards questions to its governance area rather than its review area. The code governance docs describe Review Standards as turn "your organization's engineering conventions into something that can actually be enforced," with rule enforcement as the explicit, checkable form. There is also a REVIEW.md instructions file and rule generation from PR history indexing.

The difference from CodeRabbit's approach is where the configuration lives. CodeRabbit reads files that are already in the repo. Qodo's standards are managed as governance objects in the portal, which suits an org that wants one set of rules across every repository without relying on each repo carrying the right file. It also means the standards are not part of the codebase, so a review of a rule change is not a code review.

Both approaches are legitimate and they fail differently. Repo-resident files drift when teams copy them and forget to update. Portal-managed rules drift when the portal is edited and nobody notices. Pick based on which of those two failure modes your team already handles.

Kodus and rule files

Kodus ships rule following as a first-class path rather than a side feature. Its Kody Rules overview splits rules into file-level and pull-request-level, with each rule carrying a severity of Critical, High, Medium or Low and a path scope using globs. Rules can reference other files with @file:src/services/userService.ts or @repo:team/api-standards to check consistency against a standard outside the reviewed repo, and can call MCP functions during evaluation.

The distinction that matters for teams already using a coding agent: rules file detection imports the same files CodeRabbit does, plus more, including .sourcegraph/**/*.rule.md, .opencode.json, .aider.conf.yml and docs/coding-standards/**/*. Unlike CodeRabbit's case-sensitive matching, Kodus matches case-insensitively. Nested files are scoped automatically: a services/billing/CLAUDE.md is imported and scoped to services/billing/**. Files it generates rules from are re-synced when a PR closes, and @kody-ignore keeps a file in the repo without it becoming an enforced rule.

There are two limits to plan around. On a self-hosted instance running without a valid license, the docs state that at most 10 rules are evaluated per review, oldest first, and rules past the tenth silently do not fire. Licensed self-hosted and cloud instances have no such limit. The Community plan lists "Up to 10 Kody Rules." So the self-hosted Community edition is where rule-following gets capped, which is the opposite of how most vendors structure self-managed editions.

Kodus also runs self-hosted and supports bring-your-own model keys on every plan, so on a firewalled GitLab, Azure DevOps Server or Bitbucket Data Center the rule evaluation happens against your endpoint rather than a vendor tenant. That is the same reasoning that makes the open-source CLI route attractive on those forges, and the trade-off is the rule-count cap at the free tier.

Comparing the mechanisms

Cross-repo guideline sources are the row where editions diverge most. CodeRabbit documents them as Cloud Only on Bitbucket. Kodus's @repo: reference works from a rule definition and is not gated to a single forge. If your standards live in one repo and your services live in forty, that difference is the deciding one.

What to check before you commit

The question to ask a vendor is not whether it supports custom rules. Every tool above answers yes. Ask which mechanism it uses, whether the rules live in the repo or in a portal, and whether the rule limit changes on the self-managed edition you would actually deploy.

For most teams on GitLab, Azure DevOps or Bitbucket, the sequence that works is: put your standards somewhere the team already reads them, point the reviewer at that file, and let per-path instructions handle the directories where generic guidance is worse than none. Add severity-gated rules only where a missed check has a real cost, because hard stops create merge friction that a reviewer's opinion does not.

And if you are on a self-managed forge, verify the edition before the feature. The rule-following story on a hosted tier and the rule-following story on the on-prem edition are frequently documented on different pages, and only one of them applies to where your code actually lives.