Claim Check quickstart

Shipmoor Team
June 11, 2026
3 min read

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

SourceFlagTypical confidence
One-line goal--intent "…"low
Agent prompt--prompt "…"low
Agent session transcript--session path.jsonlfrom the first user turn
Manual file.shipmoor/intent.txt in the scanned dirlow

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.

Next

Last updated on June 11, 2026

Was this article helpful?

Your response is saved on this device.