CapitalCantrip/quality-gates

Automated guardrails for software built with AI coding agents, for people who
can't review the code themselves. Checks fail the commit or the build when the
agent's code gets too complex, goes untested or adds comments, so problems get
caught without anyone reading a diff. Claude Code skills set a project up and
keep the agent to a working method that fits the size of the job. Each project
pins a version, so nothing changes until you update, and a fix reaches every
project when its pin is bumped.
Get started
Install the commands, copy the skills into the project, then run
/setup-standards: it does the rest. You can do this on your computer or from
a cloud session on your phone. To update, install the new version and repeat.
Set up a project, on your computer
You need uv and Claude Code. In the project's
folder:
1. Install the commands, pinned to a version. This puts qg-skills and the
gate commands on your computer:
2. Run this command to copy the skills into the project:
3. Start a new Claude Code session in the project and run /setup-standards.
It sets up the issue tracker docs, the gates, the record of existing debt,
the hooks and the CI checks, reports in plain words what it did, and
commits.
4. Push.
Do step 2 before step 3: a session on your computer loads skills when it
starts, so a session started earlier has no /setup-standards.
Set up a project, from a cloud session
Claude Code on the web, or the Code tab of the Claude mobile app:
1. Open a new session on the project.
2. Ask Claude to install quality-gates from GitHub with the line in step 1
above, run qg-skills, open a pull request and merge it.
3. In the same session, run /setup-standards, then ask Claude to open a pull
request and merge it.
Use it in a cloud session
Once the project is set up, a cloud session has the skills from the project's
files; it needs no install of its own.
1. Open a session on the project.
2. Send a first message, such as "hi". The session fetches the project only
when it gets one, so before that the / menu lists none of its skills.
3. Use the / commands.
Keep it up to date
Each CHANGELOG.md entry ends with what to do for that version.
In general, on your computer or by asking Claude in a cloud session:
1. Install quality-gates again with the new version number in the line from
step 1.
2. Run qg-skills and commit.
3. Run /setup-standards (on your computer, in a new session). It moves the
project to the new version and adds anything the release brought.
4. Push, or open a pull request and merge it.
Who this is for
You can describe what you want and tell whether the result works. You can't
read a diff and spot a design flaw, an untested path or an error that is
silently swallowed. That leaves four gaps:
| The gap | What goes wrong | What this repo does |
|---|---|---|
| Nobody reviews the code | The agent's bad habits ship | Gates: commands that fail the commit or the build, with no expertise needed to read the result |
| Written rules fade | "Never do X again" goes in a notes file, and X happens again | Lessons that recur become checks, not paragraphs |
| Good process and busy process look alike | Hours of polish on a design nobody agreed, or no plan where one was needed | The size of the work picks the starting step |
| Questions arrive in jargon | You choose between options you can't weigh | Every question states the stakes plainly, gives two or three options and recommends one |
Agents follow a failing tool more reliably than a paragraph of guidance, so
wherever a standard can be a command that exits non-zero, it is one.
As the quality control of a software factory
In a software factory, agents do most of the building, from plan to release,
and a person decides what to build and checks that it works. That only holds
up if the line has a quality control station that needs no one to read the
code. quality-gates can be that station:
- **It judges by numbers, not opinion.** Each gate is a command with a
threshold and an exit code, so an agent running the line can act on the
result without a person in the loop.
- **Every project gets the same standard.** Each one pins a tagged version, so
every project on the line is checked the same way. The standard changes only
through a written decision and a release, never by drift.
- **Old code doesn't stop the line, and no run makes it worse.** Existing debt
is recorded once and can only shrink, so the factory can take on a project