plumbing.sh01 / 09

plumbing.sh

Your agent says it’s done.Nothing checked.

plumb reads your repository, finds the checks it already declares, runs one, and tells you what failed and where.

why

An agent opened a pull request against my repository without reading CONTRIBUTING.md.

Everything it needed was written down. In a file. In plain English. Nothing put it in front of the agent when it mattered, so it guessed, and the guess cost me twenty minutes to find.

And the command that looks obvious usually isn’t the one that counts. On a project I work in, the real check runs a deliberately narrower set of tests across 45 named packages. Not the one anybody would type from memory.

Guess wrong and you get a green run on your machine and a red one in CI, which is worse than not checking at all.

what it does

It works out how your repository is set up.

$ plumb

PLUMB  ~/work/cobra
      66 files · 13 declared targets · 26ms

FOUND  6 verification commands
   make test        Makefile
   go vet ./...     go.mod
  ○ make lint        Makefile

NOT AVAILABLE HERE  3
  ○ make lint        binary:golangci-lint

Every command traced to the file that declares it, and a mark for whether your machine can run it. It executes nothing to tell you this.

without being told

47 build systems. No configuration file.

It identifies build files by type, not by path, so it works on a repository it has never seen, at any depth, with nothing to set up.

npmMakeGoCargoPythonMavenGradle.NETjusttoxnoxCMakepre-commitGitHub ActionsSwiftElixirErlangJuliaZigDenoDartComposerBundlerRakeTerraformBazelMesonOCamlCabalStackNimCrystalClojureLeiningensbtLuaPerlRFortranPixi

Plus whatever your CI workflows run, frequently the only place a check is written down.

what that looks like

$ plumb check

RESULTS
  FAIL  make test                          1.1s
         args_test.go:37   ×2

VERDICT  FAIL  — a repository-declared check
                 rejects this tree.

Seconds, not a review pass. The file and the line, not the log.

and what it requires

Half of what a repository expects is never a command.

Some of it is a command you can run. The rest is written in English: in CONTRIBUTING.md, in agent instruction files, in the pull-request template. plumb reads those, follows whatever they point to, and quotes every requirement with the file and line it came from.

$ plumb rules

MUST — names a command
   Agents must follow the guidelines in ./AGENTS.md
    CONTRIBUTING.md:170

SHOULD — names something concrete
   New public methods should not return null
    AGENTS.md:186

It never says whether a rule was followed. Reading a sentence cannot prove anyone obeyed it. It just puts the requirements in front of whoever is working, before they open the pull request instead of after.

the hard part

Most tools would call this your bug.

$ plumb check

RESULTS
  SKIP  make test
        not your change — make: go: Command not found

VERDICT  BLOCKED: nothing could run here.
           The checks exist; this machine cannot run them yet.

A missing Go toolchain is not a broken test. Report that as a failure once and you have taught someone to ignore you, and then you are worth nothing on the day you are right.

Same for a flake that will not reproduce, and for a pass that only covered two checks out of six. It says which.

what it costs

Zero tokens. Not fewer. Zero.

a model reviewing it
plumb
cost per run
scales with the diff
zero
latency
seconds to minutes
sub-second
same input, same answer
no
yes
what it checks against
its training
your repository

A cost argument, not an accuracy one. A model can reason about intent and plumb cannot. But for did the repository’s own checks pass, spending tokens to approximate an exit code is the wrong instrument.

* True of the tool as it stands. There is no networking code in it. Licence validation is designed and not built. When billing exists it will be the one outbound request, carrying a key and nothing from your code.

early access

Get it the day it ships.

plumb is in private development. Leave your email and you get one message, on the day you can install it. Nothing before, nothing after.

One email, when it ships. No newsletter, no tracking on this page.

Tell me what you’d point it at and I’ll tell you straight whether it would find anything in your stack, including if the answer is no.