The four gates that stop a bad agent commit before it lands

An agent that can write code can also write bad code, fast, and commit it before you have looked at a single line. The fix is not to review everything by hand. It does not scale once you are running more than one agent. The fix is to put the checks in the path itself, so a mistake gets caught before it becomes a commit, not after.

A real template built around exactly this

I have a shipped, registered project template called enforced-template, and the description I gave it is specific: a Claude Code project template with enforcement hooks, a plan gate, a tech stack enforcer, a spec gate, and an SEO validator. That is not a description of a concept I might build someday. It is a real repo sitting in my own registry, alongside the other templates I actually build from.

Each of those four pieces is doing a different job. A plan gate stops an agent from writing code before it has stated what it is about to do. A tech stack enforcer stops it from reaching for a library or pattern outside what the project actually uses. A spec gate checks the work against a written spec instead of trusting the agent's own judgment about whether it finished. An SEO validator, specific to content work, checks the output against rules that a human reviewer would otherwise have to check by hand every time.

Where the underlying discipline comes from

The instinct behind all four of those gates traces back to a principle I wrote down for myself and kept: keep the context window lean, break features into small PRs, plan first. That is from my own Claude Code development notes, captured as a live reference note, not a polished essay. The plan-first half of that note is the plan gate. The small-PR half is what makes a spec gate actually checkable, because you cannot validate a change against a spec if the change is too large and tangled to reason about in one pass.

There is also an internal SOP I keep in my ecosystem-brain skills store that lays out agentic workflow patterns as a straight comparison table, ReAct-style simple agents against a Think, Act, Observe loop, best-for use cases side by side. That same SOP carries a pre-launch checklist: reranking improves relevance, context fits token limits, responses cite sources. A checklist like that is functionally a hook. It is a set of conditions that has to pass before you consider the work done, whether or not it is wired into an actual git hook.

Why the check belongs before the commit, not after

Catching a mistake in code review is still catching it. But by the time it is in a PR, the agent has already spent the tokens, already built on top of the mistake in later steps, and you are now untangling a chain instead of blocking the first link. A gate that runs before the commit, tech stack enforcement, spec compliance, plan verification, stops the chain from forming at all. The agent either passes the check and commits, or fails it and has to fix the actual problem before anything lands.

This is also why I do not treat hooks as a one-size-fits-all thing. The enforced-template bundle has four separate gates because four separate categories of mistake exist: wrong plan, wrong stack, wrong scope against the spec, and for content work, wrong SEO structure. Bolting on a single generic "check my code" hook misses most of that. Each gate is narrow on purpose so it can actually be strict.

What I would build first if I were starting today

Start with the plan gate. It is the cheapest to add and it catches the widest range of downstream mistakes, because most bad commits trace back to an agent that started writing before it had actually settled on an approach. Add the tech stack enforcer next, since it is mechanical and easy to automate. The spec gate and any domain-specific validator, SEO or otherwise, come once you have a real spec worth checking against.

The point of all four is the same: a mistake caught before commit costs you a few seconds of a failed check. A mistake caught after commit costs you a review cycle, a revert, and whatever got built on top of it in the meantime.