.ai-review.yml

Last updated: August 2026

.ai-review.yml is an optional file committed to the root of your repository that tells Pullora how to review it. Because it lives in git, your review policy is version-controlled, code-reviewed like any other change, and identical for everyone on the team — no dashboard clicking required. Pullora detects it automatically on every review.

Full example

version: 1

reviewMode: standard

# Only post inline comments Pullora is quite sure about
minInlineConfidence: 0.85
minSummaryConfidence: 0.65

# Skip style nitpicks entirely for this repo
categories:
  - BUG
  - SECURITY
  - PERFORMANCE
  - TESTING

# Never review these paths
ignore:
  - "generated/**"
  - "**/*.snap"
  - "migrations/**"

# Your team's rules, in plain English
rules:
  - React components must not call HTTP APIs directly; use the service layer.
  - Avoid TypeScript `any` unless a justifying comment explains why.
  - Every hook that registers a subscription or timer must clean it up.
  - Public API route handlers must validate input with Zod before use.

reviewDraftPRs: false

# Only auto-review PRs into these branches
baseBranches:
  - main
  - release/**

Every key

Key	Type	Default	Description
version	number	—	Optional schema version marker (use 1).
reviewMode	quick \| standard \| deep	standard	Default review depth for this repository.
minInlineConfidence	number 0–1	0.8	Findings below this confidence are never posted as inline comments.
minSummaryConfidence	number 0–1	0.65	Findings below this are dropped entirely.
categories	list	all	Finding categories to report: BUG, SECURITY, PERFORMANCE, MAINTAINABILITY, STYLE, TESTING, DOCUMENTATION, DEPENDENCY.
ignore	glob list	locks, dist, *.min.js	Paths Pullora skips, added on top of system defaults.
rules	string list	—	Plain-English project rules the reviewer must enforce.
reviewDraftPRs	boolean	false	Also review draft PRs.
baseBranches	glob list	all	Only auto-review PRs targeting these branches.

The schema is strict: unknown keys are rejected, so a typo never silently does nothing. An invalid file does not fail your review — Pullora reviews with the remaining settings and reports the config error so you can fix it.

Writing good rules

Be specific and checkable. “DB access only through src/db/repository.ts” beats “write clean code”.
Describe your conventions, not generic best practice — Pullora already checks bugs, security issues, leaks and regressions by default.
One rule per list item. Short, single-purpose rules are enforced far more reliably than essays.

Precedence & security guardrails

When settings conflict, later layers win:

system defaults → organization rules → .ai-review.yml → dashboard settings → one-time instruction

A one-time instruction (typed when submitting a review) can only change the review mode and add guidance — it can never disable security checks, raise confidence thresholds, or ignore files.
The SECURITY category can only be disabled at the organization level; if .ai-review.yml omits it, it is re-added automatically.
ignore patterns are additive — lockfiles, dist/ and minified files are always skipped.