shipmoor review is an advisory AI code review. It looks at a change (a diff) or a set of whole files, asks an AI coding agent you provide to review it, and reports that agent’s comments as findings that inform your work without ever blocking it.
It is one of two complementary surfaces in the same shipmoor binary. The scan is the deterministic gate that can block a merge. The review is a second opinion that never can.
shipmoor scan | shipmoor review | |
|---|---|---|
| What it is | A deterministic, rule-based static analyzer | An AI code reviewer driven by your own agent |
| Who decides the finding | Fixed analyzers (one engine, identical in CLI, IDE, and CI) | Your agent’s model |
| Can it block a merge? | Yes. --fail-on turns findings into a non-zero exit | No. Advisory only, never returns the threshold exit code |
| Output | shipmoor.scan.v1 findings plus SARIF | The same shipmoor.scan.v1 findings plus SARIF |
| Determinism | Same input gives byte-identical output | Depends on the agent and model you bring |
| Entitlement | Community plus Pro | Pro (cli_pro) |
They share the same output contract on purpose. A review finding is an ordinary shipmoor.scan.v1 finding, just stamped with category: "code_review" and rule_id: "shipmoor.review.llm". Every consumer (the terminal, JSON, SARIF, the IDE, the harness, the CI poster) reads one finding shape whether it came from a scan or a review.
Four properties that define the feature
1. Advisory: it never gates
A review never fails your build. In the exit-code model (see the CLI reference), shipmoor review returns 0 whether or not it found anything. It can only return non-zero for an operational failure: bad flags give 2, and a failed agent transport or engine gives 3. It never returns the “threshold breached” exit code 1 that the scan gate uses.
This is structural, not a setting you could flip. The code_review category is excluded from the --fail-on threshold inside the engine, so a code_review finding at any severity, even one the model labels critical, contributes zero to the gate. Because there is nothing a review finding could ever block, there is also no “would-block” preview for review: there is nothing to preview.
2. Bring your own agent: you supply the reviewer
Shipmoor does not ship a model. The reviewing intelligence is a command you pass with --agent. Shipmoor resolves the change, builds a review request, and runs your command as a subprocess. It writes a JSON request to the command’s stdin and reads a JSON response from its stdout (the wire contract is in AI coding agents). Your agent owns the provider relationship: the model choice, the API key, the rate limits. Shipmoor owns only the change selection, the prompt, and the mapping of the agent’s comments into findings.
3. No hosted model, no source upload
Because the agent runs locally as your subprocess, the only network traffic is whatever your own agent already performs to reach its provider. Shipmoor itself:
- hosts no model,
- uploads no source code anywhere,
- requires no API key of its own.
If you bring an offline or local agent, a review makes no network calls at all.
4. Multi-surface, one contract
The same review runs from three surfaces, all producing the same advisory findings:
- CLI.
shipmoor review(see the CLI reference). - IDE. The VS Code extension renders review findings as Information-level advisory diagnostics, kept visually and structurally separate from scan diagnostics (see IDE).
- AI coding agents. Skills and the harness drive a review then fix loop: run the review, read the advisory findings, fix them, then re-run (see AI coding agents).
The privacy and trust model in one paragraph
shipmoor review is private by construction. Your source never leaves your machine through Shipmoor, because Shipmoor never sees a model: the review request is piped into a subprocess you chose, and only that subprocess (your agent) talks to a provider, over exactly the network path your agent already uses. The gate-versus-advisory split is the trust boundary. The deterministic shipmoor scan exit code is the only thing that can block a merge, and a review, being structurally gate-excluded, can never weaken it or be coerced into blocking. In CI this is enforced by a split-workflow design (see CI integration) so that an untrusted fork PR can never combine source checkout with the credentials your agent uses.
How it differs from the structural scan
The structural scan is the gate: deterministic analyzers catch generated-code failure modes (phantom imports, hallucinated APIs, stub paths), the same engine everywhere, and --fail-on can block a merge. The review is the advice layer: your own agent reasons over the change and posts comments, which arrive as advisory findings that travel alongside scan findings but never count toward the gate. Use both together. The scan decides pass or fail. The review comments alongside.
Where to go next
- New to it? See the Quickstart.
- Want every flag? See the CLI reference.
- Wiring your own agent? See AI coding agents.