Who it's for
Engineers letting agents open pull requests.
You'll be able to
Set up one check that people, agents and CI all run.
An agent will say its work is done. The gate is how you find out whether it is.
One command for everyone
The gate is one command that runs every check and says pass or fail. People run it, agents run it, and CI runs it. Because it is the same command, "it passed on my machine" means the same thing for all three.
make check
Three strengths
Running everything after every edit would be too slow, so the gate has three strengths. Each runs at a different moment.
| When | What runs | On failure |
|---|---|---|
| After an edit | Lint on that one file | Warns |
| Before a commit | Lint, type check, a secret scan of what is staged | Blocks the commit |
| Before a push, and in CI | All of that, plus every test, coverage of changed lines, a package audit | Blocks |
The order inside the full run matters. The secret scan and the package audit read the change before any of its code runs. Anything that runs after the change's own code can't be fully trusted, so nothing that must be trusted comes after it.
$ make check
✗Blocked before main. The agent fixes the test, or a person records why not.
One command, make check, runs every check in order: the secret scan, the package audit, lint, the type check, then every test with coverage of the changed lines.
In the first run the secret scan, the package audit, lint and the type check pass. The tests fail: 1 failed, 37 passed. The verdict: blocked before main. The agent fixes the test, or a person records why not.
After the fix the same command runs again, and every check passes: 38 tests passed. The verdict: passed. Now a person reads the checkers' report and the pull request.
If an agent or a person can skip it, it helps. If it runs on every pull request no matter what, it's the gate.
What blocks, and what only helps
Git hooks give fast feedback on your own machine, but a person or an agent can skip them. So hooks help; they are not the gate. The check in CI is the gate. It runs on every pull request, and it uses its own copy of the settings files, so a change can't quietly loosen its own rules.
Try it
In your own repository, with any AI tool:
- Write down every check you run before you merge. Put them behind one command.
- Run that command in CI on every pull request.
- Ask your agent to run it before it says it's done. Count how often it was wrong.