Pre-Merge Checks: Built-in & custom PR rules automatically enforced

All development teams claim to have pr standards, which often include requirements like: "Ensure docstrings are added," "Reference the associated issue," and "Avoid logging sensitive information."

Defining those standards is easy. Enforcing them consistently as PR volume grows is not.

If you’re an admin or team lead, you want your team to follow best practices before merging a PR every time, not just when someone remembers the checklist. If you’re a developer, you want to know immediately when something fails and how to fix it fast so you can merge.

Pre-merge Checks make your definition of done enforceable. CodeRabbit evaluates every pull request automatically using built-in validations and custom rules written in plain English. Your baseline expectations come out of the box, and your team-specific guardrails run on every PR without anyone having to remember them.

Pre-Merge Checks address the gap between simply having guidelines and actually enforcing them.

What are Pre-Merge Checks?

Pre-Merge Checks automatically evaluate a pull request whenever it opens or updates. Instead of relying on reviewers to mentally track every policy, CodeRabbit runs structured checks and reports on what passed, what failed, and what needs attention.

Checks can run in warning mode or error mode. You can introduce guardrails gradually before turning them into merge blockers and slowing developers down.

Built-In Checks

Pre-Merge Checks include built-in validations for common PR requirements most teams already expect.

• Docstring coverage thresholds: Enforces minimum documentation coverage for new or modified code against a configurable threshold (80% by default).

• PR title validation: Requires imperative verbs, character limits, or specific formatting conventions.

• PR description validation: Ensures required sections such as rollout notes or breaking changes exist.

• Linked issue verification: Confirms the PR references an approved issue or ticket.

• Issue alignment assessment: Flags when changes extend beyond the scope of the linked issue.

These checks remove repetitive review comments and keep standards consistent across contributors. No more extra tooling or manual enforcing policies.

Custom Checks

Every team has rules that do not show up in generic linters. Custom checks let you define those requirements in natural language and enforce them automatically.

Examples:

• Sensitive data in logs: Fails a PR if log statements may include passwords, API keys, tokens, SSNs, or payment data.

• Hardcoded credentials: Detects live keys or variables like SECRET, KEY, or *_PASSWORD in non-test files.

• Database migration safeguards: Requires both up() and down() methods and flags destructive changes without rollback logic.

• Breaking change documentation: Ensures public API, CLI, environment variable, or schema changes are documented in the PR and reflected in CHANGELOG.md.

• Language migration policies: Gradually phases out legacy languages by blocking new files while allowing edits to existing ones.

You define the rule once and CodeRabbit evaluates it on every pull request. That’s automated governance without brittle CI scripts or regex hacks. Check out our documentation for further details on how to write effective instructions for Custom checks.

Flexible configuration

You can configure Pre-Merge Checks in the CodeRabbit web interface or commit them to your repository using a .coderabbit.yaml file.

That means your PR policies live alongside your code and evolve with it.

Example:

reviews:
  pre_merge_checks:
    docstrings:
      mode: "error"
      threshold: 85
    title:
      mode: "warning"
      requirements: "Start with an imperative verb; keep under 50 characters."
    description:
      mode: "error"
    issue_assessment:
      mode: "warning"
  custom_checks:
    - name: "Undocumented Breaking Changes"
      mode: "warning"
      instructions: "All breaking changes to public APIs must be documented in the PR and CHANGELOG.md."

You can even introduce new guardrails in a warning state first, allowing your team to adjust. Once the rule is refined and the team is ready, transition it to an error state. Guardrails should evolve naturally with your team's process rather than being implemented abruptly.

Manual controls

You can also trigger checks directly inside a pull request.

Run all configured checks:

@coderabbitai run pre-merge checks

Test a custom rule before saving it:

@coderabbitai evaluate custom pre-merge check --name <check_name> --instructions <text> --mode <error|warning>

Override failures when necessary:

@coderabbitai ignore pre-merge checks

Why this matters

Without automated enforcement:

• Reviewers spend time re-checking predictable requirements

• Standards drift across teams

• Safeguards depend on memory

• High-signal review time gets wasted on hygiene

With Pre-Merge Checks:

• Standards apply consistently to every PR

• Risky patterns get flagged automatically

• Breaking changes get documented before merge

• Reviewers focus on architecture, tradeoffs, and edge cases

Pre-Merge Checks answer one question before code lands: Does this PR meet our standards?

If not, you get clear feedback. If it does, you merge with confidence. This transforms informal guidelines into built-in, customizable, and automatic guardrails that are fully enforceable.

Get started with Pre-Merge Checks

Enable Pre-Merge Checks in CodeRabbit and start with one rule your team already cares about like docstrings, breaking changes, migration safety, or title conventions.

Run them in warning mode and see what gets flagged. Then move to enforcement when you are ready.

Standards are easy to write. Enforcement is what changes behavior.

Try CodeRabbit on your next pull request and see what it catches. Pre-Merge Checks are available for Pro plan users and allow users to configure up to 5 custom checks per organization.