Configure

Custom Rules

Inject team-specific conventions into every PR analysis. PRMergeSafe will treat these as additional things to check, alongside its built-in rules.

Paid feature. Custom rules are available on Starter, Team, and Scale plans. Free tier uses PRMergeSafe's defaults only.

What custom rules do

Every team has its own conventions that aren't in any public coding style guide. Custom rules let you teach PRMergeSafe about them. On every PR, your rules are injected into the analysis prompt so PRMergeSafe checks for violations as part of its review.

Rules are about safety, not style. PRMergeSafe still ignores formatting and naming preferences — even if you add them as rules. Focus on things that actually break production.

Where to add rules

Go to /dashboard/settings and find the Custom Rules textarea. Add one rule per line.

Org-wide rules apply to every repo. You can also set per-repo overrides (which add to or replace the org rules) on the per-repo settings page.

Rule format

Write each rule as a plain-English imperative sentence — like you'd tell a new teammate during code review. Keep them specific.

Good rules

All new SQL queries must use parameterized statements — never string concatenation.
The /api/admin/* routes must require both authentication AND the user.role === 'admin' check.
Any change to migrations/ must include a documented rollback plan in the PR description.
New API endpoints must validate request bodies with Zod before passing to handlers.
External API calls must have a timeout and retry policy explicitly set.

Bad rules (PRMergeSafe will ignore these)

Use 2-space indentation
Prefer const over let
Functions should be under 50 lines
Variables should be camelCase

These are style preferences, not safety risks. PRMergeSafe is opinionated about staying out of style debates — your linter handles those better.

Examples by category

Auth and security

Any new route file must call requireAuth() before any business logic.
JWT tokens must never appear in URL query parameters — only in Authorization headers.
Password fields must never be logged or stringified.

Database / migrations

Migrations must be reversible — every migration needs both up() and down() functions.
Adding NOT NULL columns to existing tables must be done in two phases: nullable first, then backfill, then NOT NULL.
Dropping a column requires evidence the column has been unused for at least 7 days.

Background jobs and async

New BullMQ jobs must declare idempotency — same input must be safe to re-run.
External webhooks must verify signatures before processing the payload.

Tips

  • Start with 3–5 rules. Too many rules dilute the signal — the AI gives less attention to each one.
  • Use specific paths. "Files under src/billing/* must X" works better than generic rules.
  • Refine over time. If PRMergeSafe misses something you wish it caught, add it as a rule. If it flags too much, remove or soften.
  • Keep them short. Long rules get lost. One sentence ideally, two sentences max.
DashboardProtected Paths