.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
Theagents 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.
To define entirely new agents with custom prompts, use the
customAgents array. See Custom agents below.Custom agents
You can define custom agents using thecustomAgents array. Custom agents run in parallel alongside the built-in agents and follow the same output schema.
Rules
Therules object controls which files are reviewed and when reviews are triggered.
UX
Theux 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
TheagentReview 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
Thepricing 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:
model:in this file — the per-repo setting documented above. The committed.mergewatch.ymlalways wins, consistent with every other key on this page.- An installation-level override, if one has been set on the repository’s installation record.
- The deployment default, set per environment at deploy time.
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
Common patterns
Security-focused pipeline (e.g., payments service)
Security-focused pipeline (e.g., payments service)
.mergewatch.yml
Lightweight pipeline for high-volume repos
Lightweight pipeline for high-volume repos
.mergewatch.yml
Style-heavy pipeline for a frontend repo
Style-heavy pipeline for a frontend repo
.mergewatch.yml
Monorepo with service boundaries
Monorepo with service boundaries
.mergewatch.yml
Review only on mention
Review only on mention
.mergewatch.yml
@mergewatch review on the PR.Ignore generated code and vendored dependencies
Ignore generated code and vendored dependencies
.mergewatch.yml
Django/Python backend
Django/Python backend
.mergewatch.yml
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.
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.