Code Review & Merge Policy
"A tool that ships on time and does the job is a success. Code that's late or ships without purpose is not."
Pull requests are how we make work visible, run checks, and preserve review context. They should accelerate shipping, not become a waiting room.
Default Merge Gate
The default requirement for merging a PR is passing automated checks.
Required:
- GitHub Actions required for the target branch pass
- Formatting, lint, typecheck, test, build, or deploy checks required by that repo pass
- The PR author believes the change is ready and understands the rollout risk
Not required by default:
- A human approval review
- A fixed approval count
- Waiting on CODEOWNERS approval when the repo's required checks are green
Repo rulesets should reflect this default. If a branch protection rule or ruleset still requires one or more approving reviews, treat that as stale config unless the repo has an explicit exception documented below.
When To Request Review
Ask for review when it materially improves the outcome:
- Security-sensitive changes
- Contract, protocol, auth, payments, custody, key-management, or production-infra changes
- Large refactors where another owner has important context
- Changes crossing team boundaries
- User-facing behavior where product, design, or support context matters
- Anything you are unsure about
Reviews are still valuable. They are just requested intentionally instead of being a blanket merge blocker.
Author Accountability
If you open a PR, you own getting it to a final state.
That means:
- Mark it draft if it is not ready
- Keep the branch current enough for checks to run
- Fix failing checks or explain why they are not relevant
- Ask specific people for review when you need it
- Merge it when it is ready, or close it if it should not ship
Do not open a ready PR and leave it for someone else to discover. If you need help, ask in the relevant Slack thread or project channel.
Claiming Work
When you pick up someone else's PR or an agent-opened PR, claim it in the relevant Slack thread or project channel so ownership is clear.
Agent-opened PRs follow the same rule as human-opened PRs:
- If checks pass and the change is ready, review and merge it if you own the area
- If it is wrong, leave actionable comments or request changes
- If it needs cleanup from the agent/operator, say exactly what is needed
Draft PRs are not part of the ready-to-merge queue.
Auto-Merge
Auto-merge is allowed, but it should be enabled manually by the PR author or current owner.
Do not configure blanket automatic merging for every PR. A PR can be visible before it is intended to land, and the author should explicitly signal merge intent.
Exceptions
Some repos or branches may still need approval gates. Examples include:
- Mainnet release branches
- Security-sensitive repositories
- Compliance-controlled systems
- Repos where external requirements mandate review evidence
If a repo needs an exception, document it in that repo and make the rule explicit. The exception should name what requires approval, how many approvals are required, and why automated checks are not enough.
TL;DR
Checks gate merges. Reviews are requested when useful. Authors own their PRs through merge or closure.