CodeReviewer learns a lot from reading your codebase, but some things aren’t in the code: “we never call the payments API outside billing/”, “generated files live in src/gen/, don’t review them”, “run codegen before type-checking”. The .reviewrc.md file is where you write those down.
Where it goes
Create a file called .reviewrc.md in the root of your repository, commit it, and it takes effect on the next pull request. It’s optional: without it, CodeReviewer reviews with sensible defaults.
The file is plain markdown. Anything you write as prose becomes project context the reviewer reads before every review. Special fenced code blocks, identified by the label after the opening backticks, configure specific behavior.
A complete example
# Reviewing the Acme dashboard
- This is a multi-tenant app. Every database query MUST filter by `workspaceId`;
flag any query that doesn't.
- Money is always integer cents. Use the helpers in `lib/money.ts`; never divide
by 100 outside them.
- Server actions live in `app/actions/` and must call `requireUser()` first.
- We prefer early returns over nested conditionals, but don't comment on style
unless it hurts readability.
```ignore
docs/**
src/gen/**
**/*.snap
public/vendor/*
```
```prepare
npx prisma generate
npm run codegen
```
```build
npm run build
```
```test
npm run test:unit
npm run test:api
```
```test-context
The API tests need the seed data from `npm run db:seed:test`; they are skipped
automatically when no database is available. The `billing` e2e suite is slow;
only run it when files under billing/ changed.
```Each section explained
Project context (plain prose)
Everything outside the special blocks is read before every review. Use it for:
- Invariants the code must keep, such as tenant isolation, money handling or auth checks.
- Architecture rules: which modules may call which.
- Preferences: what you do and don’t want commented on.
Short, specific bullet points work best. “Every query must filter by workspaceId” gives the reviewer something concrete to check. “Write good code” doesn’t.
ignore: paths to skip
One pattern per line. Matching files are left out of review entirely.
**matches any number of folders (docs/**).*matches within one folder (public/vendor/*).- Lines starting with
#are comments.
Use it for generated code, vendored libraries, snapshots and fixtures, so the reviewer spends its attention on code people write.
prepare: set-up before checks
Commands to run after dependencies install and before CodeReviewer type-checks your project. Add them if your type checks depend on generated files, such as an ORM client, GraphQL types or framework route types. Put one command per line. Commands run directly, not through a shell, so pipes and && won’t work; use a separate line for each step.
build: verify fixes build
A single build command that runs after type-checking succeeds. When set, every autofix must also pass the build before it’s committed, which catches problems a type check misses, like framework-specific build errors.
Only set this if your default branch builds cleanly and reliably. A fix that fails the build is rejected, so a branch that’s already broken would block every fix.
test: commands for per-PR testing
Commands CodeReviewer runs when testing a pull request, one per line, following the same rules as prepare. If you leave this out, it chooses relevant scripts from your package.json.
test-context: guidance for testing
Free-form notes for the test pass only: environment quirks, suites to skip, known flaky areas. They’re kept out of the review context.
Tips
- Start small. Three or four invariants you care about beat two pages of style rules.
- Review the Insights page. If your team keeps dismissing a type of finding, write the preference into the project context.
- Treat it like code. Changes to
.reviewrc.mdgo through pull requests, so the team agrees on the rules, and CodeReviewer reviews the change too.