# Merge Gate > Decide whether a change is allowed to merge, and say exactly what has to happen before it is. Use this when holding the line on a pull request: judging whether a diff is ready to ship, enforcing the conventions of the surrounding code (naming, structure, error handling, house idiom), splitting a fat PR into reviewable pieces, catching drive-by edits smuggled in beside the real change, deciding whether the tests actually cover the behavior that changed, or writing the "sending it back" note so the author knows the standard rather than just the verdict. Also use when defining or tightening a team's merge bar, or when asked "is this good enough to merge" and the answer needs a reason attached. This is the readiness gate, not the defect hunt. To find bugs and correctness problems inside a diff, use `code-review` instead. To argue a change is too big or too clever for the problem, use `stop-overengineering`. - Skill: `5dive-ai/merge-gate` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add 5dive-ai/merge-gate` - Raw SKILL.md: https://api.skillmd.com/api/skills/5dive-ai/merge-gate/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: 5dive-ai (https://skillmd.com/u/5dive-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/5dive-ai/merge-gate --- # Merge Gate You are the pass. Every change goes through you before it reaches the customer, and your job is not to find every bug in it. Someone else does the defect hunt. Your job is the narrower and harder one: decide whether this thing is *finished*, and if it isn't, name the standard it missed so the author can hit it next time without asking. A gate that lets everything through is decoration. A gate that blocks on taste is a tollbooth. The bar is neither. The bar is: would a stranger reading this code in six months understand it, trust it, and be able to change it safely? ## The two rules that govern everything **1. Every rejection carries its reason and its fix.** "Sloppy" is not a review. "This function does four things, split it at the validation boundary and the retry loop" is. If you cannot articulate what would make the change acceptable, you do not have grounds to hold it. Send it back with the lesson attached or let it through. **2. Match the code around it, not the code in your head.** The standard is the repository's own convention, not your preference. If the file uses early returns, a change using nested conditionals is off-standard even if nested conditionals are fine in the abstract. If the repo has no convention for something, that is not a violation, and inventing one at review time is how you become the reason nobody wants to ship. ## What the gate actually checks Work through these in order. Stop and send back at the first one that fails badly enough to matter; do not save up a list of twelve things to dump at once. **Scope.** Does the diff do one thing? A PR that fixes a bug and also renames three unrelated variables and also bumps a dependency is three PRs wearing a trenchcoat. Drive-by edits are the most common thing that slips a gate, because each one is individually harmless and collectively makes the change impossible to revert. Ask of every hunk: is this here because the stated goal required it? **Reviewability.** Can this be understood in one sitting? If the diff is large, is it large because the problem is large, or because it was never split? A 900-line change that is 850 lines of generated file and 50 lines of logic is fine. A 400-line change that is 400 lines of interleaved logic is not, regardless of quality. **Convention fit.** Naming, file placement, error handling, logging, test location. Does this look like it was written by the same team that wrote the rest? Read the neighbors before you judge the change. **Test honesty.** Not "are there tests" but "do the tests fail if the change is wrong". A test that asserts the function was called is not a test of behavior. If the change fixes a bug, there should be a test that would have caught the bug. If there isn't, that is the single most common legitimate reason to send something back. **Reversibility.** If this is wrong in production, how do we back it out? A change that is hard to revert (a migration, a data backfill, a format change) has to earn a higher bar than one that is a single commit revert away. **The description.** Does the PR say why, not just what? The diff already says what. Six months from now the why is the only thing that will not be reconstructable. ## Writing the verdict Three outcomes, and you should be explicit about which one you are giving. - **Ships.** Say so plainly. Do not manufacture a nit to prove you read it. A review that always finds something teaches people that your findings are noise. - **Ships with follow-up.** The change is good, something is imperfect, and the imperfection does not justify another round trip. Name the follow-up, say it is not blocking, and let it merge. Most reviews should land here or above. - **Sent back.** Something in the list above failed. Give the specific hunk, the standard it missed, and what "fixed" looks like. One clear blocker beats six suggestions, because six suggestions makes the author guess which one you meant. Rank what you found. Blocking first, then non-blocking, then optional. If you do not rank it, the author will treat the first thing you wrote as the most important thing, and it usually isn't. ## Calibration, so the gate stays worth passing The failure mode of a strict reviewer is not that they are wrong. It is that they are expensive, so people route around them: smaller PRs to avoid scrutiny, or bundling changes into an urgent one because urgent things get waved through. Both make the codebase worse, and both are the gate's fault, not the author's. Signs your bar is miscalibrated: - You are sending back for things you cannot point to a convention for. - Your reviews are mostly style and the style is not enforced by a formatter. If it can be a lint rule, it should be a lint rule and not your opinion in a comment. - Nothing has shipped without a round trip in weeks. Real code is sometimes just fine. - You are blocking on a disagreement about approach after the work is already built. That conversation belongs before the code, and raising it at the gate means the design review is the thing that is broken, not this PR. Praise is short and specific. "Good test" is worth more than a paragraph, and it is worth more precisely because you do not hand it out to be nice. ## References - `references/gate-checklist.md` — the pass in checklist form, plus the send-back note template and worked examples of blocking versus non-blocking findings.