> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zenable.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Reviewer Configuration

> Configure Zenable automated code reviewers to match your team's standards

## How to Configure

To manage the reviewer configuration, customer admins can go to the [Company Settings](https://www.zenable.app/company-settings?utm_source=docs\&utm_medium=vcs-configuration\&utm_content=company-settings\&tab=configuration) page in the Zenable Management Console.

All configuration changes are applied immediately to your organization and affect all future code reviews.

## Configuration Profiles

Profiles let you maintain multiple independent configurations and assign them to specific repositories. Every tenant starts with a **Default** profile that applies to all repos unless overridden.

Each profile contains a complete, independent set of configuration options. Repos without a profile assignment use the **Default** configuration. Repos assigned to a profile use that profile's settings instead.

### Assigning Profiles to Repos

On the **Integrations** page, open a repository's settings (gear icon) and select a profile from the dropdown. Repos with an assigned profile display a colored badge showing the profile name.

### Use Cases

* **High-scrutiny repos** — enable AI reviews with premium mode, exhaustive context refinement and requirement suggestions, all finding types visible, lower preflight thresholds to catch more
* **Relaxed for prototypes** — disable preflight, hide lower-signal finding types like readability and complexity, skip clean PR comments to reduce noise
* **Team-specific defaults** — frontend repos get accessibility findings enabled with thorough context refinement; backend repos focus on security and performance with stricter quality filters

## Configuration Options

### Exclusions

#### Exclude Files

List of additional filenames or glob patterns to exclude from all Zenable integrations. This field accepts a list (array) of patterns and works like [gitignore](https://git-scm.com/docs/gitignore), including support for negation patterns.

<Note>
  A [standard list](#files-excluded-by-default) of lock files will automatically be added to the beginning of your configuration. These exclusions apply everywhere Zenable runs.
</Note>

Supports:

* **Exact filename matches** (e.g., `"package-lock.json"`)
* **Glob patterns** (e.g., `"**/*.rbi"`, `"foo/**/*.pyc"`)
* **Negation patterns** with `!` prefix (e.g., `"!keep-this.json"`)

<AccordionGroup>
  <Accordion title="Basic Glob Pattern Examples">
    - **`*.log`** - Skip all log files in any directory
    - **`**/*.tmp`** - Skip all .tmp files in any directory (recursive)
    - **`src/**/*.test.js`** - Skip all .test.js files under src/ directory
    - **`docs/*.md`** - Skip markdown files directly in docs/ directory
    - **`build/*`** - Skip all files directly in build/ directory
    - **`**/node_modules/**`** - Skip all files in any node\_modules directory
    - **`example.py`** - Skip files named example.py in any directory
    - **`**/example.tmp`** - Skip files named example.tmp in any directory (i.e. the same as `example.tmp`)
    - **`/example.py`** - Skip example.py only in the root directory
  </Accordion>

  <Accordion title="Negation Pattern Examples">
    Negation patterns start with `!` and allow you to include files that would otherwise be skipped. **Order matters** - the last matching pattern wins.

    **Skip all log files except important.log**

    * Add `*.log` to skip all log files
    * Add `!important.log` to include important.log

    **Skip all files in build/ except those in build/keep/**

    * Add `build/**/*` to skip all files in build/
    * Add `!build/keep/**/*` to include files in build/keep/

    **Escaping files that literally start with !**

    <Note>
      To skip files that **literally start with `!`** (fairly rare), escape the exclamation mark with a backslash: `\!filename.txt`
    </Note>
  </Accordion>
</AccordionGroup>

#### Exclude Branches

List of branches to skip. You can use [python regex](https://docs.python.org/3/library/re.html#regular-expression-syntax) to match the branch names. We will check all the patterns in the list, if any pattern match, the PR opened in that branch will be skipped.

### Smart Filters

#### Preflight Checks

Preflight lets you optionally skip reviews based on static analysis findings.

* enabled: Whether to enable preflight. (default: false)
* max\_changed\_lines: Maximum total changed lines allowed before skipping the review. (default: 2500)

#### PR Quality Filter

PR Quality Filter lets you optionally skip reviews based on the quality of the PR. We measure the PR quality based on analysis of the whole PR and the generated review. We measure multiple dimensions of quality, such as code quality, architecture quality, testing quality, documentation quality, security quality, and maintainability. This generates a final overall quality score for the PR, which is used to determine if the PR review will be sent or not.

Skip reviews with quality score below the threshold can be a useful way to skip reviews on pr that are not fully done, and reduce the noise in your PRs.

* enabled: Whether to enable pr\_quality\_filter. (default: false)
* quality\_threshold: The minimum quality score required to post a review. Valid values are between 0 and 1. (default: 0.5)

#### Review Drafts

Controls whether Zenable reviews draft pull requests (GitHub) and merge requests marked as draft / work-in-progress (GitLab).

* **`true`** — draft PRs/MRs are reviewed as soon as they are opened.
* **`false`** — draft PRs/MRs are skipped silently. They will be reviewed automatically when transitioned to "ready for review".

Setting this to `false` is useful if your team relies heavily on draft PRs for in-progress work and prefers to only receive Zenable reviews once the author explicitly marks the PR as ready.

* review\_drafts: Whether to review draft PRs/MRs. (default: true)

### Reviewer Context and Feedback

#### Reactions

Configuration section for controlling which reactions are added during reviews. This allows you to enable or disable specific reactions that the reviewer generates.

##### Taking a Look Reaction

Controls the "eyes" emoji reaction (👀) that is added at the start of a review. The reaction is automatically removed once the review is complete.

**Default:** `true` (👀 reaction is added)

#### Comments

Configuration section for controlling which comments are posted during reviews. This allows you to enable or disable specific informational comments that the reviewer generates.

##### No Findings Comment

When set to `true`, posts the "Nice work! 😎" comment when no issues are found in the PR. Set to `false` to disable this comment - when disabled and there are no findings, no review comment will be posted at all.

**Default:** `true` (comment is posted)

<Note>
  These settings only affect informational comments. Reviews with actual findings or suggestions will always be posted regardless of these settings.
</Note>

#### PR/MR Risk Assessment

Surfaces a Zenable-assessed risk level on each PR/MR. The assessment is produced by an LLM that considers the diff together with the review findings, and picks one of four levels along with a short rationale.

| Level        | Indicator | Meaning                                                                                    |
| ------------ | --------- | ------------------------------------------------------------------------------------------ |
| **Low**      | 🟢        | Minor or well-contained change.                                                            |
| **Medium**   | 🟡        | Reasonable change with some areas to double-check.                                         |
| **High**     | 🟠        | Noteworthy impact; review with care before merging.                                        |
| **Critical** | 🔴        | High likelihood of severe impact (security, data loss, outages, or compliance violations). |

When enabled, Zenable appends a small `Risk: <emoji> <Level>` heading to the review body, followed by a collapsible `Risk analysis` block with the rationale.

##### Mode

Controls how the risk assessment is surfaced.

* **`off`** — The risk assessment step is skipped entirely.
* **`comment_only`** — The risk section is included in the review body. No labels are applied to the PR/MR.
* **`comment_and_label`** — The risk section is included in the review body, and a matching label is applied to the PR/MR.

**Default:** `comment_and_label`

##### Labels (`comment_and_label` only)

When `comment_and_label` is selected, Zenable ensures the following four labels exist in the repository/project and applies the one matching the assessed level. The risk labels are mutually exclusive: if a previous review assigned a different level (for example `high`) and the code has since improved, the stale label is removed before the new one is applied.

* `zenable/risk:low`
* `zenable/risk:medium`
* `zenable/risk:high`
* `zenable/risk:critical`

#### Finding Types

Each review comment is classified into one of the following labels. All are shown by default — deselect a type to hide comments with that label.

* **Bug** — Incorrect behavior, logic errors, or broken functionality
* **Readability** — Hard-to-follow code structure, unclear naming, or poor formatting
* **Performance** — Inefficient algorithms, unnecessary allocations, or scalability concerns
* **Complexity** — Overly complicated logic that could be simplified
* **Security** — Vulnerabilities, unsafe patterns, or missing input validation
* **Inconsistency** — Contradicts existing patterns, conventions, or nearby code
* **Accessibility** — Missing or incorrect accessibility support (ARIA, keyboard nav, color contrast)
* **Mistake** — Typos, copy-paste errors, or accidental omissions
* **Other** — Issues that don't fit the above categories

**Default:** All types visible. Deselect a type to suppress comments with that label.

### IDE/Agent Hook

Settings that govern how the Zenable CLI emits findings to coding agents (Claude Code, Cursor, OpenCode, etc.) when the hook fires after edits.

#### Triage Instructions

The preamble emitted as `<instructions>...</instructions>` ahead of findings the first time findings surface in an agent session. The agent uses this preamble to decide how to triage each finding (label categories, fix-versus-defer guidance, output format).

Customize the text per config profile when your team wants a different triage protocol — for example, a stricter "fix everything before continuing" stance, or a more permissive "label only, don't fix" workflow. Leave the field empty to fall back to the in-binary default that ships with the CLI.

The block is always emitted; setting an empty value falls back to the default rather than suppressing it. To change the wording for a specific repo, assign that repo to a config profile with the desired text.

## Default Configuration

### Preflight

* **enabled**: `true`
* **max\_changed\_lines**: `2500`

### PR Quality Filter

* **enabled**: `true`
* **quality\_threshold**: `0.5`

### Review Drafts

* **review\_drafts**: `true`

### PR/MR Risk Assessment

* **mode**: `comment_and_label`

### IDE/Agent Hook

* **triage\_instructions**: built-in default (the CLI ships a multi-line preamble that labels findings as `addressed`, `deferred`, `out-of-scope`, `rule-mismatch`, or `already-mitigated`).

### Files Excluded by Default

The following files are automatically excluded by default across all Zenable integrations:

```toml expandable theme={null}
conda-lock.yml
bun.lock
go.mod
requirements.txt
uv.lock
.terraform.lock.hcl
Gemfile.lock
package-lock.json
pnpm-lock.yaml
yarn.lock
composer.lock
poetry.lock
pdm.lock
Cargo.lock
go.sum
Package.resolved
Podfile.lock
mix.lock
*.ico
*.jpeg
*.jpg
*.png
*.svg
```

By default, no branches are skipped.

## Troubleshooting

If you're having issues with the GitHub or GitLab reviewers, try the following:

* Verify your configuration in **Company Settings → Configurations** is correct.

* The skip\_branches option uses python regex to match the branch names. Ensure your regex patterns are valid.

* If any of these solutions don't work, contact our support team at [support@zenable.io](mailto:support@zenable.io).