Policy files

Many repos already describe how they want code reviewed: REVIEW_POLICY.md, APPROVAL_POLICY.md, AGENTS.md, CLAUDE.md. MergeJudge reads these from the base branch tip (never from the PR head) and puts them in the system prompt as a trusted <repo_policy> block. PR content stays in a separate untrusted block.

• Policy can only make review stricter. It cannot lower a lane.
• Edits to a policy file inside a PR don't affect that PR's review.
• Caps: policy.max_each_bytes (8 KB) and policy.max_total_bytes (8 KB). Longer files are truncated fairly across the listed files so one long file cannot starve the others.
• An empty policy_files: [] turns injection off.

policy_files: [REVIEW_POLICY.md]   # only this file
policy_exclude: ["CLAUDE.md"]      # or skip specific files
# policy_files: []                 # turn it off to save tokens

What to put in REVIEW_POLICY.md

Keep it short. The model already looks for bugs, security holes and broken logic; use the policy for what is specific to this repo. Aim for a few dozen lines, well under the 8 KB cap.

Include

• What matters here (auth, payments, migrations, deploy config, public API contracts).
• Risky areas that should at least go to review, even when the change looks small.
• Security expectations (secrets, CSRF, authz checks, dependency pins).
• When a change should be block until a human looks.
• What to ignore (style nits, formatting, docs-only wording) so the model spends tokens on real issues.

Skip

• Long style guides (prefer a linter).
• Generic "write clean code" advice.
• Anything that would try to make a risky change safer than the rules floor — that is ignored.

Copy-paste template

Save this as REVIEW_POLICY.md on your default branch and trim it to your repo.

# Review policy

## What matters in this repo
- Auth, session and permission checks.
- Database migrations and schema changes.
- Deploy / CI config (`.github/`, `wrangler.toml`, `_headers`).
- Public HTTP APIs and webhook handlers.

## Raise to review even if small
- Any change under `src/auth/`, `**/migrations/**` or `deploy/`.
- New third-party scripts, iframes or outbound webhooks.
- Changes to rate limits, feature flags that gate money or PII, or CORS.

## Block until a human looks
- Removal or weakening of a safety guard (`set -e`, `persist-credentials: false`, lockfile freezes).
- Hard-coded secrets, private keys or live API tokens in added lines.
- Direct writes to production credentials or billing code without a linked ticket.

## Ignore
- Pure formatting / import order.
- Typo fixes in comments and docs that do not change behaviour.
- Test-only renames with no production impact.

## Security expectations
- New endpoints that touch user data must check authz on the resource, not only "logged in".
- Do not log tokens, cookies or raw PII.
- Prefer allowlists over denylists for redirects and CORS origins.

After you merge it to the base branch, the next review on that repo will load it automatically. See also How it works (policy is step 4 / the policy-files bullet) and .mergejudge.yml (policy_files, policy_exclude, policy.max_*_bytes).