Quickstart

Shipmoor Team
June 11, 2026
5 min read

Shipmoor runs after your coding agent finishes and before you open a PR. It scans the change for the failure modes agents introduce — hallucinated dependencies, calls to APIs that don’t exist, handlers that return success without doing the work — and, on a license, checks whether the change actually did what it was asked to do.

This quickstart takes you from install to your first finding in about five minutes. Everything here runs locally: no account, no telemetry, and no source ever leaves your machine.

1. Install

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

The installer drops a single shipmoor binary in ~/.shipmoor/bin and prints the exact export PATH line to add if that directory isn’t already on your shell PATH. Verify the install:

shipmoor version
# shipmoor 0.4.0

One binary serves every tier. The free Community scan works with no login; a local license unlocks the paid IC features (Claim Check, Agent Skills, and more). You don’t download a different build to upgrade.

2. Run your first scan

From inside any repository, run shipmoor with no arguments to see the welcome banner with your detected languages, branch, and the suggested next command:

shipmoor
              ⟨ ◆ ⟩

     ███████ ██   ██ ██ ██████  ███    ███  ██████   ██████  ██████
     ██      ██   ██ ██ ██   ██ ████  ████ ██    ██ ██    ██ ██   ██
     ███████ ███████ ██ ██████  ██ ████ ██ ██    ██ ██    ██ ██████
          ██ ██   ██ ██ ██      ██  ██  ██ ██    ██ ██    ██ ██   ██
     ███████ ██   ██ ██ ██      ██      ██  ██████   ██████  ██   ██

         v0.4.0  community  ·  verify agent work before review

Then scan the code your agent just wrote. The fastest path is to scope the scan to your uncommitted changes rather than the whole repo:

shipmoor scan --changed

Shipmoor leads with a one-line verdict, then groups findings by file with blockers first, and names the exact command to run next:

✗ 1 blocker  ·  scanned 7 changed files (python, typescript)

src/billing/webhook.ts
  [high] phantom_import · line 3
    Imports 'fast-retry', missing from the manifest and lockfile.
    → next: shipmoor explain phantom_import

Run `shipmoor scan --changed --json` for machine output, or
`shipmoor explain <rule>` for the why and the fix.

Tip — scope to the change. A full-repo shipmoor scan . on a project whose third-party dependencies aren’t installed can report a lot of phantom-import noise. Scoping to —changed, —staged, or —diff <range> keeps the scan focused on what your agent actually touched.

3. Understand a finding

Ask Shipmoor to explain any rule. It tells you what the failure mode is, why it matters, and what to check:

shipmoor explain phantom_import

The findings Shipmoor catches are high-confidence, generated-code failure modes — not style nits. The most common are:

FindingWhat it means
Phantom importThe code references a package that isn’t in the manifest or lockfile.
Hallucinated APIA function, method, endpoint, or local symbol is called even though it doesn’t exist.
Stub pathA handler returns success while the real persistence, payment, or side effect is missing.

See the full list in Findings & rules.

4. Get machine output for CI

The same scan emits deterministic JSON and SARIF from the same evidence — and uses stable exit codes so it’s safe to gate a build on:

shipmoor scan --changed --json   --output shipmoor.json
shipmoor scan --changed --sarif  --output shipmoor.sarif
shipmoor scan --changed --fail-on high
Exit codeMeaning
0Clean — no gate fired
1Findings met the gate (this is not an error; the JSON is still written)
2Usage error (bad arguments or config)
3Scan failed

Wiring this into GitHub Actions is two steps — install, then scan --changed with SARIF upload. See GitHub Actions.

5. Next: check the change against its claim

A scan tells you the change is structurally sound. Claim Check (part of the Shipmoor IC plan) answers the question a linter can’t: did this change do what the task asked?

Once you’ve signed in (shipmoor login), pass the change’s intent alongside a scoped scan:

shipmoor scan --staged \
  --intent "Add a Stripe webhook handler for failed payments (payment_intent.payment_failed)"

If the change wires the handler, you get a VERIFIED verdict. If it claims to but doesn’t — say it quietly logs the request body instead — Claim Check reports the gap and names the divergence. The claim check is advisory by default and never changes your exit code; deterministic evidence decides what blocks, and an LLM opinion can only ever advise. Start with the Claim Check quickstart.

Where to go next

  • Installation — channels, PATH, and shipmoor upgrade.
  • Core concepts — the scan vs the claim check, severity, tiers, and the local-first guarantee.
  • Scanning your code--changed, --staged, --diff, and --patch.
  • Claim Check — the IC feature that checks a change against its intent.
  • Agent Skills — run the Shipmoor loop from inside Claude, Codex, Cursor, or Aider.
Last updated on June 11, 2026

Was this article helpful?

Your response is saved on this device.