Shipmoor 0.6.0: a code review that runs your agent, not ours

The Shipmoor scan is a deterministic instrument. It catches the structural ways agent-generated code goes wrong: a phantom import, a hallucinated local API, a stub that returns nothing, a test that asserts the function was called but never that it did anything. Those are facts. A rule fires or it does not, the same way every time, and the exit code is something you can put in front of a merge button.

There is a layer the scan was never built to reach. After the structure is sound, a reader still has to ask the soft question. Does this change actually do the right thing, and does it do it well? Is that the right SQL? Should that connection be closed? Is that the discount, or the last item’s price? For a long time the only answers were a human reviewer, or a hosted AI reviewer that you mail your source code to and hope for the best.

Shipmoor 0.6.0 adds a third answer: Code Review.

It is an advisory AI review of your change. It runs locally, it runs your own coding agent, and it reports findings without ever blocking your build. Shipmoor hosts no model and uploads no source. The reviewer is the agent you already pay for and already trust.

One command

curl -fsSL https://dl.shipmoor.dev/install.sh | bash
shipmoor version
# shipmoor 0.6.0

shipmoor review --agent claude

That is the whole thing. You make a change, you run shipmoor review --agent claude, and Shipmoor drives your Claude CLI over the diff and turns its reading into advisory findings. Here is a real one, on a freshly written discount function:

○ Advisory review - 3 findings on your change
payments.py · your own agent · advisory only
────────────────────────────────────────────────────────
payments.py
  high   :20  SQL injection
    The discount code is formatted straight into the query string, so a crafted
    code can rewrite the query.
    fix  use a parameter: "SELECT pct FROM discounts WHERE code = ?", (code,)
  high   :23  missing None check
    fetchone() returns None for an unknown code, so row[0] raises a TypeError
    instead of a clean error.
  medium :19  connection leak
    apply_discount opens a connection and never closes it, unlike get_order
    above. Wrap the body in try/finally.
────────────────────────────────────────────────────────
✓ review complete · exit 0 · advisory findings never block your build

It read the injection, the silent crash, and the leak, and it noticed that the new code drifted from the file’s own correct pattern. That is the kind of judgment that used to require a person.

Bring your own agent

The word “your” is doing real work here. Shipmoor does not run a model. It speaks a small JSON contract on stdin and stdout, one request in and one response out, and anything that speaks it can be the reviewer.

Two presets are built in and need no setup beyond the agent you already have:

shipmoor review --agent claude    # drives your Claude CLI
shipmoor review --agent codex     # drives your Codex CLI

If you want something else, point --agent at any command that speaks the contract. A reference agent ships in the docs, and you can wrap your own. The one thing to know is that a bare claude -p is not that command. It takes a prompt and prints text, which is why the claude preset exists: it bridges your CLI to the wire contract for you.

Why bring your own agent at all? Three reasons. Your code stays on your machine, because the review runs where the code already lives. You use the model and the account you already chose, under your own relationship and your own rate limits. And Shipmoor stays a tool, not a data plane: it has no model to host, no inference bill to pass on, and nothing of yours to keep.

It never gates, on purpose

This is the most important sentence in the release. The advisory review always exits zero. It cannot fail a build, flip a check, or hold a merge. The deterministic scan is still the only thing that gates, and shipmoor scan --fail-on is still the line that enforces it.

That split is deliberate. A model is good at reading and bad at being a gate. So Shipmoor lets the model read, surfaces what it found, and leaves enforcement to the rules that behave the same way every time. Review informs. The gate enforces. You never have to wonder which one just failed your pipeline.

Five places it shows up

The same review, the same --agent claude, reaches you wherever you already work:

CLI. shipmoor review on your working tree, a commit range, or staged files.
IDE. Advisory findings appear as Information diagnostics in a separate collection. They never raise an error squiggle and never count toward your problem totals.
CI. An advisory pull-request comment job, built on a hardened split workflow so a fork cannot reach your agent key. It posts. It never blocks the merge.
Agent Skills. A review then fix loop your coding agent runs: review the change, repair what it finds, re-review, and never call it done on the advisory pass alone.
Agent Harness. Review findings ride through the local feedback loop as advisory signal, alongside the deterministic gate.

What did not change

It is worth being explicit about the load-bearing parts that 0.6.0 left exactly where they were:

The deterministic scan. Same rules, four languages, same categories. The gate you pin in CI behaves the same today as it did yesterday.
The output contract. Review findings are ordinary shipmoor.scan.v1 with category: code_review, plus SARIF 2.1.0. A script that read scan JSON reads review JSON.
The exit-code vocabulary. Clean, over threshold, usage, failure. Review simply never returns the gating one.
Local-first and no source upload. Sign-in and licensing run through the Console and never see your code. The review runs in your environment, driven by your agent.

If you pin Shipmoor in CI, this is a safe upgrade. You gained a reading pass. Your machines parse the same bytes they did before.

Try it

curl -fsSL https://dl.shipmoor.dev/install.sh | bash
cd path/to/your/repo
# make an agent-authored change, then:
shipmoor review --agent claude

If you have an agent-authored change sitting in your working tree right now, that is the run we would most like to hear about. What did the review catch that your scan could not? What did it miss? Where did it earn its place in your loop, and where did it just add noise? The honest answer to those questions is what shapes the next release.

For the full walkthrough across the CLI, the IDE, CI, and agents, see the Code Review docs. For where this sits next to the deterministic engine, How the Shipmoor scan works is still the canonical reference.

From the shipmoor.dev Engineering Team with love ❤️