Claim Check answers the question a linter can’t: did this change do what the task asked? This gets you from install to your first claim check in about five minutes.
1. Sign in
Claim Check is an IC feature — it needs the intent_scan entitlement. A plain structural scan works without it.
shipmoor version # shipmoor 0.4.0
shipmoor login
2. Run your first claim check
The claim check appears when you scan a changeset (--changed, --staged, --diff <range>, or --patch <file>) and supply the change’s intent:
shipmoor scan --staged \
--intent "Add a Stripe webhook handler for failed payments (payment_intent.payment_failed)"
If the change actually wires the handler:
Claim check VERIFIED · maturity: verified · coverage: 100%
✓ A handler is bound to the Stripe payment_intent.payment_failed event.
Not yet checked:
∅ Failure-path handling
∅ Webhook signature verification
If it claims to but doesn’t — say it quietly logs the request body instead — the same scan reports the gap, and does not change your exit code (it’s advisory by default):
Claim check GAP DISCLOSED · maturity: gap_disclosed · coverage: 100%
✗ A handler is bound to the Stripe payment_intent.payment_failed event.
3. Read it as three numbers
The badge carries three independent axes — don’t conflate them:
- maturity — how well-checked the claim is (
verified/partial/gap_disclosed/unprobed/inferred). - coverage — what fraction of expectations were checkable here.
- confidence — how sure we are of the intent itself (shown on the
Source:line).
Not yet checked lists expectations Shipmoor doesn’t probe yet — honest silence, not a pass. Full detail in Reading the verdict.
4. Where intent comes from
| Source | Flag | Typical confidence |
|---|---|---|
| One-line goal | --intent "…" | low |
| Agent prompt | --prompt "…" | low |
| Agent session transcript | --session path.jsonl | from the first user turn |
| Manual file | .shipmoor/intent.txt in the scanned dir | low |
Supplying two agreeing sources (e.g. --intent + --prompt) raises confidence to medium — which matters if you turn the gate on. See Providing intent.
5. Make it block (opt-in)
By default nothing blocks. To gate a merge on a deterministic failure, copy the shipped policy, set gating.enabled: true, and pass it:
shipmoor scan --staged --intent "…" --prompt "…" \
--verdict-policy .shipmoor/verdict-policy.yaml # may exit 1
shipmoor scan --staged --intent "…" --prompt "…" \
--verdict-policy .shipmoor/verdict-policy.yaml --would-block # preview, exit 0
The gate has a floor it cannot be configured below: it blocks only on a deterministic major gap at non-low confidence — never on a guess, a low-confidence intent, or an LLM opinion. See Turning on the gate.
6. Optional — an LLM second opinion (never blocks)
For the long tail Shipmoor has no probe for, you can opt in to an advisory opinion from your own coding agent. It runs as an isolated sub-agent in your tool — Shipmoor calls no model and uploads no source — and the result is labeled inferred, excluded from the score, and can never gate. See BYO-Judge.