Skip to main content
The .mergewatch.yml file controls how MergeWatch reviews pull requests in a repository. Place it at the root of your repository’s default branch (usually main).

Configuration priority

MergeWatch resolves configuration in the following order. Each layer overrides the one before it:
1

Built-in defaults

Hardcoded in the MergeWatch Lambda. These apply when no other configuration is present.
2

Installation-level settings (DynamoDB)

Set via the dashboard. Apply to all repositories in the installation.
3

Per-repo .mergewatch.yml

Checked into the repository. Overrides both built-in defaults and installation-level settings.
A .mergewatch.yml in the repository always wins. If you set maxFiles: 100 in the dashboard but maxFiles: 20 in the YAML file, the repo uses 20.

Validation

MergeWatch validates the .mergewatch.yml file on the first webhook it receives for the repository. If the file contains errors — invalid YAML, unknown properties, or type mismatches — MergeWatch posts the validation errors as a comment on the pull request so they are immediately visible to the author.

Full annotated example

.mergewatch.yml

Property reference

Top-level properties

Agents

The agents object is a boolean map that toggles each of the eight built-in review agents on or off. Set an agent to false to disable it entirely.
You do not need to list all agents. Omitted agents default to true (enabled). To disable a single agent, include only that agent with false.
To define entirely new agents with custom prompts, use the customAgents array. See Custom agents below.
Built-in agents:

Custom agents

You can define custom agents using the customAgents array. Custom agents run in parallel alongside the built-in agents and follow the same output schema.

Rules

The rules object controls which files are reviewed and when reviews are triggered.
rules.ignorePatterns is deprecated. Use top-level excludePatterns instead — it is the canonical field for filtering files out of the diff. Existing .mergewatch.yml files keep working: any entries under rules.ignorePatterns are folded into excludePatterns at parse time and a one-time deprecation warning is emitted.

UX

The ux object controls how the review comment is formatted and what sections are shown. Tone directives:

Path filters

MergeWatch has two top-level path-filter fields. They operate at different layers — see Skip Rules for the full picture.
.mergewatch.yml

Agent-authored PRs

The agentReview object controls how MergeWatch handles pull requests authored by coding agents (Claude Code, Cursor, Codex, etc.). When detection matches, the review pipeline applies stricter prompts and tracks how many iterations the agent took to reach a passing state.
.mergewatch.yml

Pricing overrides

The pricing field maps a model ID to its per-token price (USD per 1M tokens) and is used by the cost-estimation pipeline. Set it when you run a model that is not in MergeWatch’s built-in price table — for example, a self-hosted Llama on Ollama or a custom Bedrock provisioned-throughput endpoint.
.mergewatch.yml

Which model actually runs

model: is resolved against two other sources. Highest precedence first:
  1. model: in this file — the per-repo setting documented above. The committed .mergewatch.yml always wins, consistent with every other key on this page.
  2. An installation-level override, if one has been set on the repository’s installation record.
  3. The deployment default, set per environment at deploy time.
Self-hosted differs in one respect: the LLM_MODEL environment variable is an operator pin rather than a default, so it overrides everything above — including this file. Omitting model: therefore means “use whatever this deployment is configured with”, not “use the value shown in the table above” — which is why the Default column reads (deployment default) rather than naming a model. The review log line records which source won:
Before MergeWatch v0.1.x, model: was silently ignored on the hosted service — the deployment default was used regardless of what this file said. Self-hosted always honored it. If you set model: and saw no change, that was why; it now works on both.

Minimal configuration

If the defaults work for you, the smallest valid configuration is:
.mergewatch.yml
This enables all eight built-in agents with their default prompts, uses Claude Sonnet via Bedrock, and reviews PRs automatically.

Common patterns

.mergewatch.yml
Disables style and diagram agents. A custom agent adds domain-specific security checks for payments services.
.mergewatch.yml
Uses the cheaper Haiku model, disables low-priority agents, and suppresses info-level findings. Good for repos with frequent small PRs where speed and cost matter more than comprehensive review.
.mergewatch.yml
Custom agents add React/TypeScript conventions and frontend-specific security checks alongside the built-in agents.
.mergewatch.yml
Custom agents enforce architectural boundaries. All built-in agents remain enabled.
.mergewatch.yml
MergeWatch stays silent until someone comments @mergewatch review on the PR.
.mergewatch.yml
.mergewatch.yml
Three custom agents with Django-specific prompts alongside the built-in agents.

Where the file lives

The .mergewatch.yml file must be placed at the root of the repository’s default branch (the branch GitHub shows when you visit the repo — usually main or master). MergeWatch reads the file from the default branch, not from the PR’s head branch. This means configuration changes in a PR do not take effect until they are merged.
If you rename your default branch, MergeWatch automatically detects the new default on the next webhook. No action is required.

maxFileDiffKB

Maximum size, in KB, of a single file’s diff section. Default 128. A file whose diff exceeds this is dropped from review even if no excludePatterns entry matches it. excludePatterns only catches artifacts you have already met. This catches the next one: a hand-written source file with a 128KB+ diff essentially does not exist, so a section that large is generated, vendored, or minified. Dropped files are always reported in the logs, distinctly from pattern exclusions — a pattern match is your intent, a size drop is MergeWatch’s.
Related: MergeWatch also refuses to review a diff that would exceed the configured model’s context window, posting a neutral “Review skipped — diff too large” check that names the estimated size, the budget, and the model. Previously such a PR failed with a raw provider error.