Skip to main content

Configure Reviews

Buzzbin has two levels of review configuration:

  • organization defaults
  • repository overrides

If a field is not overridden at repository level, the organization-level value is used. Inheritance is field-by-field, not all-or-nothing per repository.

What you can configure​

Core capabilities​

You can enable or disable these capabilities per organization or repository:

  • Code Review
  • Comment Answers
  • Reviewer Suggestion
  • Title & Description
  • Related MRs
  • Custom Review Instructions

If a capability is disabled, it produces no output and consumes no cost for that capability.

Output language​

You can set the output language to Persian or English. This affects review comments, answers, and generated MR text.

Finding categories​

Instead of a single strictness level, Buzzbin uses an allowed category list. Common examples:

  • Security
  • Bug
  • Performance
  • Maintainability
  • Testing
  • Documentation

If only some categories matter for your team, keep those and remove the rest so the output stays focused.

Ignored paths​

You can exclude files or directories from review with globs such as:

  • **/migrations/**
  • **/*.lock
  • **/dist/**

Model slots​

Buzzbin exposes two model slots:

  • Review model for Code Review and Title & Description
  • Answer model for Comment Answers

This lets you use a deeper model for review and a faster or cheaper one for short answers.

Custom instructions​

If your team has specific standards, you can inject guidance such as:

  • be stricter on error handling
  • ignore style issues in generated files
  • always check context propagation in Go services

Additional controls​

Depending on the capability, you can also configure:

  • answer only when the bot is mentioned
  • reviewer suggestion count
  • auto-assign reviewers
  • Title & Description mode: SUGGEST or AUTO_APPLY
  • label suggestions and auto-apply labels
  • auto-approve when no blocking issue is found
  • daily run cap to limit usage per repository

Organization defaults vs repository overrides​

The general rule is:

  • organization settings seed new repositories
  • later organization changes only affect fields that were not explicitly overridden in the repository
  • some fields such as excluded reviewers only make sense at repository level

When repository-specific overrides help​

Repository overrides are especially useful when:

  • one repository needs a different output language
  • one repository should allow a narrower set of finding categories
  • some paths in one repository are generated or noisy
  • you want a different daily cap or reviewer suggestion behavior

Cost impact​

Selected models, enabled capabilities, and run volume directly affect wallet usage. If you want tighter cost control, start with these three levers:

  1. disable low-value capabilities
  2. lower the daily run cap
  3. pick a more suitable answer model

For the billing side, see Wallet and billing.