Release / Slopbrake 0.1.0 / MIT
Slopbrake: Brakes for the Software Factory
Slopbrake is out. It gives a Python or TypeScript repository the brakes a coding agent needs: one gate, a reviewer with fresh eyes that commits its fixes, and a rule that says which changes wait for a human.
Every rule it checks can be proven to fail on a real violation. That part is not optional.
0.1.0
released Sept 26
MIT
open source
15
proofs in verify
30+
rules, each with an ID
0
Python dependencies
Py · TS
stacks supported
A factory needs brakes
Coding agents write code faster than anyone can review it. That is the whole appeal, and it is also the problem. Matt Pocock put it in one line in Fixing the PR Bottleneck: without brakes, a software factory becomes a slop cannon.
The slop is rarely a syntax error. It is a test suite that grows by forty tests and catches nothing. It is a helper that reaches three folders deep into a module it should never touch. It is ten pull requests that all look equally safe, one of which quietly drops a table.
Pocock's talks and his skills describe how to handle this: layered review, a reviewer that fixes instead of commenting, one-way and two-way doors, and retros that turn repeated comments into checks. Slopbrake turns those ideas into rules that fail a build.
Every agent change takes the same road
- 01
Agent implements
ticket → seams → red → green
- 02
Layer 1 · scripts/check
lint · types · boundaries · tests · tautology · mutation floor
- 03
Layer 2 · reviewer
fresh context, two axes, commits its own fixes
- 04
Door?
computed floor the agent can raise, never lower
- 05
Merge or a human
two-way: merge-eligible · one-way: you decide
The slop hides in the tests
Here is the kind of test an agent writes when it is told to "add tests." It passes. It will pass forever. It can never disagree with the code, because it is the code:
from shop import discount
from shop.pricing import MEMBER_THRESHOLD
def test_threshold():
assert MEMBER_THRESHOLD == 100 # restates the definition
def test_discount():
total = 150
assert discount(total, True) == total - 10 # recomputes the answer the way the code does
The fix is an independent expectation: a literal, a worked example, the spec. assert discount(150, True) == 140 can catch a bug; total - 10 never will. Property checks such as out == sorted(out) and symbolic expectations such as validate(x) == ERR_TOO_LONG pass untouched. If an assertion really does need to restate a constant, the suppression has to carry a reason: # slopbrake: allow-tautology: 280 is the published API limit.
Tautology is the easy case. The harder one is a test that looks fine but would pass whatever the code did. For that, Slopbrake mutation-tests only the lines you changed, which keeps it fast enough to run on every push.
What it catches
Tautological tests
Constants asserted against themselves, expected values rebuilt from the test's own inputs, expect(true).toBe(true). An AST check in Python, an ESLint rule in TypeScript.
Tests that can't fail
A mutation score below the floor on the lines you changed. A standard-library mutator for Python, StrykerJS with line ranges for TypeScript.
Reaching past a module
Imports that go around a module's entry points, and import cycles. Pocock's dependency-cruiser rules, with a stdlib port for Python.
Under-declared risk
A PR body without a Door and Blast Radius, or a door declared lower than the rules compute. A migration can't be called two-way.
Destructive git
push --force, reset --hard, clean -f, branch -D and checkout . are blocked in agent sessions. A plain branch push still works.
Stopping on red
An agent with uncommitted code can't finish while the fast gate is red. After three red attempts it may stop, and it has to say so.
The full rulebook has more than thirty rules across the gate, tests, deep modules, the reviewer, door triage, retros and harness hygiene. Each has an ID, a mechanism (check, review or process) and, where it can be checked, a proof. It is all in docs/RULES.md.
Every rule is proven, not configured
A guardrail you have never seen fire is a guardrail you are hoping about. So slopbrake verify works in a throwaway git worktree, and for each checkable rule it plants a real violation: a deep import, a tautological test, an assertion-free test, a migration labelled two-way, a PR body with no door. The check has to fail and name the rule. Then the violation is removed and the check has to pass again. A check that crashes can't pass a proof.
Spend human attention where it can't be undone
Reviewing every agent PR by hand doesn't scale, and it shouldn't have to. Most changes are two-way doors: if they are wrong, you revert them. A few are one-way: a migration that drops a table, a change to auth or billing, an email that goes out, the gate itself.
Every PR declares a Door and a Blast Radius. Slopbrake computes a floor from path and content rules in .claude/door-rules.yml, and the agent may raise the door but never lower it. A two-way door with a green gate and a clean review is merge-eligible. A one-way door waits for you. You review the classifier and its rules, not every PR.
$ python3 scripts/slopbrake/door_classify.py --base main
door: one-way
- touches migrations/0007_drop_legacy.sql (path rule '**/migrations/**')
- touches migrations/0007_drop_legacy.sql (path rule '**/*.sql')
- migrations/0007_drop_legacy.sql:1 adds 'DROP TABLE legacy_accounts;' (content rule 'DROP TABLE')A reviewer that never saw the conversation
The implementer is under the most context pressure, so it doesn't carry the coding standards; the reviewer does. Two reviewers run in parallel on separate axes, Standards and Spec, with the diff, the ticket and the gate output, and nothing from the implementer's session.
Fixes land as commits, not comments
A single fix-mode reviewer commits each local, confident finding as a review: commit, with at most three fix-and-gate rounds. Anything that changes behaviour or touches a one-way door goes under Open questions for a person.
Where Slopbrake departs from the talks
Most of Slopbrake is Pocock's thinking made mechanical. Four choices are ours, and any mistakes in them are ours too:
Mutation testing
The objective test of "can this test fail?" It starts at a 60% floor on changed lines, and each retro can raise it.
Tautology is a check
Pocock's own retro skill says a mechanical rule gets a deterministic check, full stop. So T1 fails the build instead of living in a standards file.
The door is computed
Pocock has the agent declare its door. We add a floor from path and content rules that the agent can raise but never lower.
One committer
Two review axes run in parallel, report-only. A single fix-mode reviewer commits, so two agents never race on one branch.
Standing on Matt Pocock's work
Slopbrake exists because Matt Pocock did the hard thinking in public and released it under MIT. mattpocock/skills is vendored unmodified, with our additions appended rather than edited in: tdd, code-review, retro, pr, setup-ts-deep-modules (the seed of verify: "prove the rules bite"), git-guardrails-claude-code and more. The vocabulary comes from his dictionary of AI coding, and the tautology rule from his post "Tautological tests considered harmful".
The README credits each rule to the skill or talk it came from. The PR skill's "shape of the change" section is Dex Horthy's show-me from humanlayer/skills. Slopbrake is an independent project; if you like it, go read the originals.
Try it on a repo you care about
Python 3.11+ and a git repository. --dry-run first, so you can see every file before it lands.
uv tool install git+https://github.com/GreyforgeLabs/slopbrake # or pipx
slopbrake init path/to/repo --dry-run # see exactly what it would add
slopbrake init path/to/repo # add it; never overwrites files you own
slopbrake verify path/to/repo # prove every rule bites
# every command takes --json · exit codes: 0 ok, 1 gap or failed proof, 2 usageRepo-owned files such as scripts/check, CODING_STANDARDS.md and .claude/door-rules.yml are written once and are yours to edit. Kit-owned checks are refreshed by init --update. Your existing .claude/settings.json is merged, not replaced.
Know the edges before you adopt it. This is 0.1.0. The gate, its checks, the git hooks and CI run anywhere, but the reviewer agent and the two session hooks are written for Claude Code. Python and TypeScript are the only stacks today. Mutation testing starts at a 60% floor, and your retros are what should raise it.
Slopbrake questions, answered
›What is Slopbrake?
Slopbrake is an open-source (MIT) kit from Greyforge Labs that adds guardrails for coding agents to a Python or TypeScript repository. It installs one gate command, a fresh-context reviewer that commits its fixes, door triage for pull requests, and a retro process that turns repeated review comments into checks.
›What is a tautological test?
A test whose expected value is derived from the code under test, so it can never disagree with it: asserting a constant equals its own definition, or recomputing the answer the same way the implementation does. Slopbrake's T1 rule fails the build on these; the fix is an independent expectation such as a literal or a worked example.
›How is Slopbrake related to Matt Pocock's skills?
Slopbrake vendors mattpocock/skills unmodified under its MIT license and builds on the ideas in his talks: three review layers, one-way and two-way doors, a reviewer that commits, and retros that turn mechanical findings into checks. Slopbrake's additions are the checks themselves, mutation testing on changed lines, a computed door floor, and the verify proofs. Slopbrake is an independent project.
›Does Slopbrake need Claude Code?
The gate (scripts/check), its checks, the pre-commit and pre-push hooks and CI run anywhere. The reviewer agent, the implement-ticket skill, the destructive-git guard and the stop-only-when-green hook are written for Claude Code.
›Will it overwrite my files?
No. slopbrake init --dry-run lists everything it would add. Repo-owned files such as scripts/check and CODING_STANDARDS.md are written once and are yours; kit-owned checks are refreshed by --update; .claude/settings.json is merged, not replaced.
›How do I know the checks work?
Run slopbrake verify. For each checkable rule it plants a real violation in a throwaway worktree and requires the check to fail and name that rule, then pass again. A check that crashes cannot pass a proof.
Slopbrake 0.1.0
Let the factory run fast.
Give it brakes that work.
Run verify on your own repo and tell us which proof you wish existed. The best issues are review comments you keep writing by hand.