Green = auto-merge (fully algorithmic)

Green auto-merge is the policy that pull requests scoring Green in the automated evaluation system are merged to the main branch automatically, without human review. The decision is fully algorithmic: if all quality gates pass and no conditions trigger Yellow or Red, the code ships. No human approves the merge; the algorithm does.

This is L4 (Optimized) - a significant psychological and organizational step beyond L3. At L3, the AI review agent is an advisor: its comments inform human judgment, but humans make the final call. At L4, the algorithm makes the call for Green PRs. Human engineers are not in the loop for routine changes.

The algorithmic decision is grounded in a question: what does human approval add for a PR that has already passed every quality check? If the tests are comprehensive, the lint enforces architecture, the AI agent found no issues, and the diff is within safe parameters - what is a human reviewer adding by clicking "Approve"? In most cases: nothing except elapsed time and cognitive overhead. The approval is a ritual, not a judgment.

Green auto-merge eliminates that ritual for cases where it provides no value. The human review process continues for Yellow PRs (changes that require judgment) and Red PRs (changes with blocking issues). What changes is that routine changes - the clear majority of day-to-day commits - no longer wait in a human review queue.

The prerequisites are significant: a trustworthy Green evaluation (high confidence that Green means safe), comprehensive tests, a complete lint configuration, and a well-calibrated AI review agent. Teams that attempt auto-merge before these foundations are in place will introduce incidents and retreat. Teams that build the foundations first find auto-merge the natural next step.

The impact of auto-merge compounds with PR volume. For a team submitting 50 PRs per day where 60% qualify as Green:

• 30 PRs per day no longer wait in the review queue - each was waiting an average of 3-4 hours. That's 90-120 hours of wait time eliminated daily.
• Developer flow is preserved - code submitted in the evening (when human reviewers aren't working) merges overnight. Developers return in the morning to a merged change, not a waiting PR.
• Reviewer capacity is recovered - the 20 PRs per day that still require human review get better attention than when reviewers were handling 50. Quality of human review for Yellow/Red PRs goes up.
• Deployment frequency increases - with 30 additional PRs merging per day, the pipeline has more deployable units. If your pipeline deploys on every merge, you go from ~20 deploys/day to ~50 deploys/day without any change to the deployment infrastructure.

For teams accustomed to human review as a quality gate, the psychological barrier to auto-merge is real. "What if something slips through?" is a legitimate concern. The answer is: the same algorithmic evaluation that caught it before review catches it now. If the quality gate was working (which you verified at L3), it continues working at L4. The difference is that there's no human in the loop for Green PRs - but there wasn't meaningful human contribution for those PRs anyway.

1. Verify your Green criteria are conservative and trustworthy - Before enabling auto-merge, audit 60 days of historical PRs. What proportion would have scored Green under your criteria? Randomly sample 20 of those PRs and review them manually. If you find issues in more than 1-2%, tighten the Green criteria before proceeding.
2. Implement auto-merge in your repository - GitHub has native auto-merge support: enable it in branch protection settings. When all required status checks pass (including your Green evaluation check), GitHub automatically merges the PR. GitLab has a similar Merge When Pipeline Succeeds feature.
3. Configure the Green status check - Your Green evaluation CI step must output a passing status for GitHub's auto-merge to trigger. If the evaluation produces Yellow or Red, the PR stays in the queue for human action.
4. Establish a monitoring policy - For the first 90 days of auto-merge, have someone review the "auto-merged last 24h" list each morning. Are any auto-merged PRs creating follow-up issues? This monitoring establishes confidence and catches any gaps in the Green criteria.
5. Create an override mechanism - Allow authors (or reviewers) to mark a PR "requires review" even if it would score Green. Some changes feel important to have a human review even if they meet all technical criteria. The override should be easy to use without penalty.
6. Track the post-merge defect rate - Auto-merged PRs are a new category in your defect attribution data. Are auto-merged PRs more or less likely to introduce bugs than human-reviewed PRs? This data validates the system and identifies criteria gaps.

Enabling auto-merge before the quality gate is proven. The most common failure mode: teams skip the validation step, enable auto-merge, and within weeks have an incident caused by an auto-merged PR that their existing quality gates didn't catch. This destroys confidence in the system. The 30-day dry run is not optional.

Defining Green too loosely under pressure. "Our Green rate is only 30% - if we loosen the criteria, we could get 60%+ auto-merging." The right response to a low Green rate is to fix the underlying quality issues, not to lower the bar. A looser Green definition with more incidents is worse than a strict one with a lower auto-merge rate.

Not communicating the change to the team. If developers aren't told that Green PRs will auto-merge, they'll be confused when they return to find their PR merged without any human approval. Announce the change, explain the criteria, and make it clear how to opt out with an override.

Losing the ability to revert. Auto-merged PRs ship to main the same as any other PR. Ensure your deployment and rollback processes are healthy before enabling auto-merge. If a bad auto-merge reaches production, you need to be able to revert it quickly. Trunk-based development with feature flags is the ideal complement to auto-merge.