Your agents slop. Take control.

Deterministic project rules for your coding agent. They kick in when it touches a file or runs a command, and hold until met: files only where you allow, right skills loaded first, work proven by diff or logs. Not a suggestion in CLAUDE.md or AGENTS.md.

Website →	Docs →

See it in action

Watch the 2-min video →	Claude Code session replay →

One Claude Code session, one prompt: make every capability in harness-mocks, our fakes of Claude Code, Codex and Cursor, real for every harness, proven by recordings of the real thing. It split the work across parallel agents, and sloprail checked every step.

Why not just hooks?

	Hooks, CLAUDE.md, skills, AI reviewers	sloprail
When rules appear	after a mistake, if you add them	first: the agent sets them up before any change that will repeat, and they stay
The rule	text the model reads, or a hook script you write	a check that verifies the work, run by code
Shell changes	the hook sees the command, not which files it changed	checks every file the change touched
What gets judged	one tool call at a time	sliced the way each rule needs: one file, a module, or the whole commit
Push and merge	blocked only if your hook pattern matches	blocked until the checks pass
Review	an AI reviewer re-reads it every time; what it checked is opaque	every verdict saved with its rule and reason, reused until the code changes

Install

sloprail is installed per project: run these from the project's root.

Claude Code:

claude plugin marketplace add sloprail/sloprail --scope project
claude plugin install sloprail@sloprail-marketplace --scope project

Codex (then enable the plugin in the project's .codex/config.toml, and trust its hooks with sr-session codex-trust):

codex plugin marketplace add sloprail/sloprail
codex plugin add sloprail@sloprail-marketplace

Cursor (plugins are per user; this also installs the binaries):

curl -fsSL https://raw.githubusercontent.com/sloprail/sloprail/main/install.sh | sh -s -- --harness cursor

The first session after that installs the sr* binaries the hooks call, once: the release matching the plugin's version, checksum-verified, into ~/.local/bin, and says so. From then on every tool call and turn-end runs through sloprail — you don't run anything by hand. Install has each harness's verification step and what differs between them.

Set SLOPRAIL_NO_AUTO_INSTALL=1 and run

curl -fsSL https://raw.githubusercontent.com/sloprail/sloprail/main/install.sh | sh

(or go install ./services/... from a checkout).

How it works

Rules live under .sloprail/, one folder per rule:

• gate/ checks an action before it happens
• file-guard/ checks what a file holds, on every commit
• context/ is a mode other rules depend on
• file-guard/structure.yaml lists where files may go at all

Your harness calls sloprail on every tool call and turn end, and sloprail runs the rules that apply.

To make verdicts block merges, run sr-checks verify in CI: see the Quickstart.

You've seen these happen

• The task gets rewritten to match the work
• After enough compaction, it games the score instead of doing the work
• A request fell through the cracks
• The same fact, copied into two files, now disagreeing
• It acted without loading what it needed first
• The "mechanical" refactor silently rewrote your code