SlopCop

Static analysis deep enough for CI, fast enough to run on every edit.

slopcop sends one git patch, from the base commit to the working tree, to the hosted check API at https://slopcop.com. The service applies it, runs the hosted policy catalog plus the repository rules you selected, and returns the report: every finding with its severity, the file and line that triggered it, and the certainty behind it. The analysis is Bifrost, an open-source static analysis engine rather than a language model, so a finding traces back to a rule instead of to a guess.

There is no local analyzer and nothing to install per language: the CLI ships the change and prints what comes back, and it never decides on its own that there is nothing to check. The command is built for agents and one-shot CI: no prompts, one request, and the analyzer's exit contract.

Install

npm, PyPI, the release archive, and the PowerShell installer all install the same release binary for macOS, Linux, and Windows on x64 and arm64, so slopcop version reports which release it came from. The Go toolchain can build that binary from source instead.

npm

npm install --global @brokkai/slopcop
slopcop --help

The tarball carries the release binary for every supported platform, so it needs no Go toolchain. npx @brokkai/slopcop runs it without installing it.

PyPI

pip install brokk-slopcop

pipx install brokk-slopcop or uv tool install brokk-slopcop puts it in an environment of its own. The wheels carry the release binary, so no Go toolchain is needed either. The package is brokk-slopcop because PyPI already has an unrelated project named slopcop; the command it installs is still slopcop, and python -m brokk_slopcop runs the same binary.

Release archive

Each release publishes slopcop_v<version>_<os>_<arch>.tar.gz (.zip on Windows) holding the binary, README.md, and LICENSE, plus a checksums.txt covering every archive. Download them from https://github.com/BrokkAi/slopcop/releases/latest and check the sha256 before unpacking:

ver=0.0.3; os=linux; arch=amd64   # darwin/arm64 on Apple silicon
base=https://github.com/BrokkAi/slopcop/releases/download/v$ver
curl -fsSLO "$base/slopcop_v${ver}_${os}_${arch}.tar.gz"
curl -fsSLO "$base/checksums.txt"
grep "${os}_${arch}" checksums.txt | sha256sum -c -   # shasum -a 256 -c - on macOS
tar -xzf "slopcop_v${ver}_${os}_${arch}.tar.gz" slopcop
sudo install -m 755 slopcop /usr/local/bin/slopcop

PowerShell installer

irm https://raw.githubusercontent.com/BrokkAi/slopcop/master/install.ps1 | iex

It takes the latest release, verifies the archive against checksums.txt, installs slopcop.exe to %LOCALAPPDATA%\Programs\slopcop, and adds that directory to the user Path. SLOPCOP_VERSION, SLOPCOP_INSTALL_DIR, and SLOPCOP_NO_MODIFY_PATH override its defaults.

Go

go install github.com/BrokkAi/slopcop/cmd/slopcop@latest

Go 1.25 or newer is required to build. A plain go install reports dev as its version; in a clone, make install stamps the version from git describe.

Enable it in an agent

The binary carries the agent skill that teaches a coding agent how to run slopcop. slopcop init installs it into each well-known skills directory whose harness is present, and names what it did:

A skill that is already there is left alone by init, so running it again is safe. slopcop login and every check also install the skill in those directories, rewriting one that differs from the skill bundled into the binary, so an agent follows the instructions of the slopcop version it runs; local edits to an installed skill do not survive them. slopcop init --no-skill skips the install and any update of it.

Sign in

slopcop login                           # browser device flow
slopcop login --token "$SLOPCOP_TOKEN"  # existing credential, for CI and agents

The browser flow prints a URL and a code and stores the token once the login is approved. The service URL defaults to https://slopcop.com; --service, $SLOPCOP_SERVICE, or a stored value override it.

The credential lives in slopcop/config.json under the user config directory and is written owner-only. slopcop logout clears it.

Precedence:

Check

slopcop                          # check the change in the current checkout
slopcop check --format json      # same, machine-readable
slopcop --root ../repo --base HEAD~1

The base commit defaults to the merge base with the branch upstream, then the merge base with origin/HEAD, then HEAD. The service must already have the base commit in its clone; a missing one comes back as the service's base_not_found message and remedy.

Every run sends one check request, even when the working tree matches the base and the patch is empty. A clean result or a failure always comes from the service.

Flags:

What is sent

One git patch from the base commit to the working tree. An empty change is sent as an empty patch, not filtered out. The patch carries committed but unpushed work, unstaged edits, untracked files, deletions, renames, mode changes, and binary content. Git-ignored files stay out, except selected .slopcop/policies rules, which must travel because the service evaluates them from the patched checkout.

The service owns the limits on what a check accepts. When a change is too large or touches too many files, the service's payload_too_large response is printed verbatim; the CLI does not impose its own limits.

Every check also runs the hosted catalog. Rules under .slopcop/policies/**/*.rqlp are added automatically unless --no-policy-discovery is set.

New and pre-existing findings

A check fails only on findings the change introduced or touched: the service marks a finding new when it is in a file the change writes and its lines meet a line the change added, or the line beside one it removed. Findings that were already in the code are counted, never fail the check, and are listed only with --show-existing. A change that introduces nothing exits 0, however many findings the repository already holds.

Ignore a false positive

Each finding a check reports carries an id. When a finding is a false positive, ignore it:

slopcop ignore 0f8fad5b-d9cb-469f-a165-70867728950e

That finding is not reported again for this repository. Ignoring covers that one finding, its rule plus its place in the code, in its repository for your workspace; the rule keeps reporting everything else. Ignoring a finding twice is fine. ignore uses the same login and service URL as a check, exits 0 with a one-line confirmation, and otherwise exits 2 with the service's message and remedy; finding_not_found means the id is unknown or comes from a check outside your workspace.

Output and exit codes

The service answers structured data; the CLI renders it. human prints one block per new finding, with an ID: line when the service names one, then the pre-existing ones with --show-existing, a summary line such as 1 new finding across 1 file(s); 72 already in the code (--show-existing lists them) | Analysis complete, and any omitted or incomplete checks. json prints status, baseCommit, summary (newFindings and existingFindings count the split), findings (each with new and its id), incomplete, and failure when the analysis did not complete. sarif prints a SARIF 2.1.0 log whose results carry baselineState new or unchanged and the finding id in properties["slopcop.findingId"]. --format and --show-existing only change the rendering, never the request, so the service answers the same check whichever is used.

An inconclusive check fails the check only when it concerns a file the change writes. One about other files is listed on an Inconclusive outside the change line (inconclusiveElsewhere in json, a note notification in sarif) and never changes the exit code. A check that timed out counts wherever it is. The service can place an inconclusive check only once Bifrost reports which files it concerns; until then every one counts as in the change.

The service applies --fail-on and sets the status; the exit code follows it. The CLI always sends --fail-on, defaulting to finding: a check fails only on findings the change introduced, so any of them, a note or an unrated one included, is worth fixing before the change lands. The service's own default for a request without failOn is Bifrost's warning; pass --fail-on warning to match it. New findings that cross --fail-on exit 1 even when some check did not complete.

While the service answers check_running, the CLI waits the Retry-After it names and asks again until --timeout runs out; every ask attaches to the same running check. If it is still running then, the CLI exits 3, prints the service's message and remedy on stderr, and in json prints {"status": "pending", "retryAfter": 5, "message": …, "remedy": …} on stdout (sarif prints a run with slopcop.status pending). Running the same check again picks up the same analysis.

Service failures print the closed contract exactly: message, remedy, and any install URL. The codes, messages, and remedies are defined by the service in server/src/check.rs of BrokkAi/bifrost-service; the CLI does not rewrite them. The remedies name no client, so when one says to sign in the CLI adds the slopcop login command after it. A failed request prints no report on stdout.

API

The CLI calls POST <service>/v1/check with a bearer token:

{
  "repoUrl": "https://github.com/owner/name",
  "baseCommit": "0123456789abcdef0123456789abcdef01234567",
  "change": "<base64 git patch>",
  "selection": {"files": [".slopcop/policies/rule.rqlp"]},
  "failOn": "finding"
}

The service rejects any other field. The response carries status, baseCommit, applied, summary, findings, incomplete, and failure when the analysis did not complete. Against a service from before findings were marked new, the CLI treats every finding as new, as that service gated on all of them. Non-2xx responses carry code, message, remedy, retryable, and an optional installUrl.

Each finding in the response carries an id; a service from before findings could be ignored omits it.

slopcop ignore <id> calls POST <service>/v1/ignore with the same bearer token and {"findingId": "<id>"}, and gets back {"findingId": "<id>", "status": "ignored"}. Failures use the same closed contract, including finding_not_found.

slopcop login uses the device flow: POST /api/device returns a deviceCode, userCode, verificationUri, expiresIn, and interval, and POST /api/token returns 202 while pending or 200 with a token once approved. The polling codes are authorization_pending, slow_down, expired_token, and access_denied.

Development

make test        # go test ./...
make vet         # go vet ./...
make build       # bin/slopcop-<goos>-<goarch>
make cross-check # linux, darwin, and windows on amd64 and arm64
make npm-test    # node --test npm/test
make wheels      # pypi-dist/, one wheel per release target

Releases are tag-driven. Pushing a v*.*.* tag runs GoReleaser, which builds linux, darwin, and windows for amd64 and arm64, packages tar.gz archives (zip on Windows) with checksums.txt, and publishes the GitHub release. .goreleaser.yaml is the single source of truth; CI runs goreleaser check and a snapshot build on every change, and make release-check runs the same locally when GoReleaser is installed. The same tag push then packs @brokkai/slopcop from those release archives and publishes it to npm with trusted publishing, so the package needs no npm token.

The same tag also packs a wheel per release target from the binaries GoReleaser just built, installs the wheel for every platform GitHub can run, and publishes brokk-slopcop to PyPI with trusted publishing, so that package needs no PyPI token either.

Layout: