Custom rules allow you to enforce your organization’s specific best practices across all pull requests, ensuring consistency and compliance with your team’s established standards.

Defining a custom rule

To define a rule, navigate to the AI review page in cubic and click “Add rule”.

Each custom rule includes:

  1. A Name
    A concise title, like “Prevent N+1 Queries” or “Require Sentry Error Handling.”

  2. A Description
    A clear, natural-language instruction the AI will use, such as “Flag code that may cause multiple database calls inside loops.”

    Be as clear and explicit as possible; the more specific you are, the better the results.

  3. Optional Path Filters
    Use Glob patterns to limit where the rule applies (or exclude certain paths). This is especially helpful for monorepos, where different directories often require different rules. For example:

    • Include: backend/** to apply the rule only to files under a backend folder.
    • Exclude: !tests/** to ignore test files and focus on production code.

Custom rules are defined at the repository level, and will be applied to all pull requests in the repository. This means that you can enforce different custom rules for each repository.

Common custom rule patterns

Custom rules help catch deviations that human reviewers might miss, ensuring consistent application of your team’s standards. When a violation of a rule is detected in a pull request, the AI will comment directly on the affected lines.

Importing rules from Cursor

If your team uses Cursor rules, you can easily import these into cubic by clicking the Sync Cursor Rules button on the AI review page.

cubic will analyze your Cursor rule files, suggest suitable custom rules, and let you select which ones you’d like to enable.

Limitations

  • Rule limit: Each repository can have a maximum of 5 custom rules. Consider combining related checks into single rules to stay within this limit.
  • Single check per PR: cubic currently performs rule checks only once when the pull request is first opened. Subsequent commits won’t trigger additional checks yet.
  • Potential false positives: Occasionally, the AI might incorrectly flag or overlook certain scenarios. Consider AI feedback as helpful guidance rather than definitive judgments.

Tips for effective custom rules

  • Combine related checks: There’s a limit of 5 rules per repository, but you can combine multiple related checks into a single rule if it makes sense. Grouping semantically similar things together usually works well and helps you stay within the limit.

  • Leverage path filters in monorepos: When working with monorepos, use Glob patterns to target specific files or folders. The “glob wizard” and “glob testing” tools in the advanced section are super handy for making sure your patterns do exactly what you expect.

  • Use the auto-suggestion feature: When creating a rule in the UI, look for the little wand icon that can help auto-word your rule if you’re stuck. This can provide a good starting point that you can then refine.

  • Complement existing tools: Custom rules should focus on checks that standard tools like ESLint or Prettier might miss, such as business logic validations or team-specific conventions.

Next steps

Overview: Understand how cubic reviews pull requests by default.

Custom rules allow you to enforce your organization’s specific best practices across all pull requests, ensuring consistency and compliance with your team’s established standards.

Defining a custom rule

To define a rule, navigate to the AI review page in cubic and click “Add rule”.

Each custom rule includes:

  1. A Name
    A concise title, like “Prevent N+1 Queries” or “Require Sentry Error Handling.”

  2. A Description
    A clear, natural-language instruction the AI will use, such as “Flag code that may cause multiple database calls inside loops.”

    Be as clear and explicit as possible; the more specific you are, the better the results.

  3. Optional Path Filters
    Use Glob patterns to limit where the rule applies (or exclude certain paths). This is especially helpful for monorepos, where different directories often require different rules. For example:

    • Include: backend/** to apply the rule only to files under a backend folder.
    • Exclude: !tests/** to ignore test files and focus on production code.

Custom rules are defined at the repository level, and will be applied to all pull requests in the repository. This means that you can enforce different custom rules for each repository.

Common custom rule patterns

Custom rules help catch deviations that human reviewers might miss, ensuring consistent application of your team’s standards. When a violation of a rule is detected in a pull request, the AI will comment directly on the affected lines.

Importing rules from Cursor

If your team uses Cursor rules, you can easily import these into cubic by clicking the Sync Cursor Rules button on the AI review page.

cubic will analyze your Cursor rule files, suggest suitable custom rules, and let you select which ones you’d like to enable.

Limitations

  • Rule limit: Each repository can have a maximum of 5 custom rules. Consider combining related checks into single rules to stay within this limit.
  • Single check per PR: cubic currently performs rule checks only once when the pull request is first opened. Subsequent commits won’t trigger additional checks yet.
  • Potential false positives: Occasionally, the AI might incorrectly flag or overlook certain scenarios. Consider AI feedback as helpful guidance rather than definitive judgments.

Tips for effective custom rules

  • Combine related checks: There’s a limit of 5 rules per repository, but you can combine multiple related checks into a single rule if it makes sense. Grouping semantically similar things together usually works well and helps you stay within the limit.

  • Leverage path filters in monorepos: When working with monorepos, use Glob patterns to target specific files or folders. The “glob wizard” and “glob testing” tools in the advanced section are super handy for making sure your patterns do exactly what you expect.

  • Use the auto-suggestion feature: When creating a rule in the UI, look for the little wand icon that can help auto-word your rule if you’re stuck. This can provide a good starting point that you can then refine.

  • Complement existing tools: Custom rules should focus on checks that standard tools like ESLint or Prettier might miss, such as business logic validations or team-specific conventions.

Next steps

Overview: Understand how cubic reviews pull requests by default.