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:
| Finding | What it means |
|---|---|
| Phantom import | The code references a package that isn’t in the manifest or lockfile. |
| Hallucinated API | A function, method, endpoint, or local symbol is called even though it doesn’t exist. |
| Stub path | A 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 code | Meaning |
|---|---|
0 | Clean — no gate fired |
1 | Findings met the gate (this is not an error; the JSON is still written) |
2 | Usage error (bad arguments or config) |
3 | Scan 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, andshipmoor 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.