Ship faster with merge rules

Every mature team eventually writes the same sentence: “make sure the tests pass and two people have looked at it before merging.” It’s the review checklist, and it lives in onboarding docs, in PR templates, in Slack pins, and in the heads of the people who’ve been there longest. Each of those places is one reorg away from being out of date — and the team either pays the cost of inconsistency or the cost of enforcing it by hand.

Merge rules fix this by codifying the rules the team already agrees on, in one place, in a format the platform can evaluate. “High-risk PRs need two approvals,” “migrations to billing/data schemas require a security review,” “a rebase is required before merge if the base branch has moved.” Each is a small rule, but together they replace a checklist that was easy to skip.

The second-order effect is even bigger than the first: once the rule is in code, the team can change it without a 30-minute meeting. The review checklist becomes a living artifact — versioned, reviewable, diffable in the same way the codebase is. That pushes review culture from “what did we agree to last quarter?” to “what’s the rule version on this repo?”

Faster shipping follows. Not because the rules let anything through — they usually block — but because the team stops restarting the same conversation. The right PR merges itself; the risky one waits, and the reason is visible on the PR. The reviewer’s job shifts from re-deriving the checklist to adjudicating judgment calls, which is the part humans are actually good at.