sb-verify-completion git:20260903.489d306A

Immutable. This exact content is served forever at /api/v1/blob/2712027a258a9289.

---
name: sb-verify-completion
description: Consequence-free check of an explicit completion or success claim against fresh evidence. Changes nothing; do not use to advance a named Spec whose implementation may be accepted.
argument-hint: "<claim>"
---

# Verify one claim

## Apply project language style

Before authoring any artifact or user-facing prose, read:

```sh
specbind rule read language-style --for consume
```

Apply returned policy only to natural-language prose. `NO_CHANGE RULE_ABSENT`
means no additional project preference; any `ERROR` line stops the workflow.

Use this **before** saying a task is done, a defect is fixed, a command passed,
or an implementation is complete — including before trusting a subagent's report
that any of those is true.

You answer one question and change nothing.

This is not the Spec completion gate. When the user asks whether a named Spec's
completed implementation is done and a `GO` should record completion evidence,
use `sb-validate-implementation` instead. Use this skill when the subject
is the claim itself and the result must remain consequence-free.
If both readings appear possible, stay in this consequence-free workflow unless
the user explicitly authorized recording completion on `GO`; completed Tasks do
not supply that authority.

```sh
specbind protocol read completion-verification
```

## What you are judging

A **claim**, not a Spec. Something someone is about to assert. State it back
precisely in the narrowest form actually being made, because the most common
false completion is not a lie — it is evidence for a part being accepted for the
whole.

When the claim is about the current work for a named Spec, run
`specbind check traceability <spec>` and fix the claim's Requirement scope from
its exact `Active requirement set`. Requirements outside that set describe the
accepted baseline, not unfinished current work. Include them only when the user
explicitly claims the whole subsystem or product behavior, and never infer the
active set from Design prose or front matter.

Then find what would prove *that* claim, and require evidence from the current
state of the code.

## Run the check yourself

Wherever you can reproduce it, run it. A report is a claim, not evidence, and
this skill exists mainly because "the subagent said it succeeded" is persuasive
in the moment.

When you are handed output you cannot reproduce — from another run, from an
earlier state, from the user — **say so**, and treat the claim as resting on
evidence you did not observe. That is usually `MANUAL_VERIFY_REQUIRED`, not
`VERIFIED`.

## Return the verdict

```text
## Verification
- VERDICT: VERIFIED | NOT_VERIFIED | MANUAL_VERIFY_REQUIRED
- CLAIM: <the claim, as you understood it>
- EVIDENCE: <what you ran or read, and what it returned>
- GAP: <where the claim exceeds the evidence, or none>
```

- **`VERIFIED`** — the evidence covers exactly this claim.
- **`NOT_VERIFIED`** — the check failed, the evidence is stale or partial, the
  claim is broader than what was shown, or work remains blocked or uncovered.
- **`MANUAL_VERIFY_REQUIRED`** — a mandatory check could not be performed here.
  Nothing is known to be wrong, and nothing is known to be right.

**The third is not a softer second, and never a route to the first.** Turning
"could not check" into "checked" is the failure this skill exists to prevent.

Never narrow a check, skip a case, or substitute a cheaper command to reach
`VERIFIED`.

## You are not a workflow stage

**Change nothing — including when the verdict is `VERIFIED`.**

Confirming that an implementation is complete puts you one step from recording
that completion, and the step looks like helpfulness. It is not. Completion
evidence is written by `sb-validate-implementation` through a handshake
that rechecks things you never looked at: gate freshness, contract review
freshness, milestone convergence, and a clean revision.

`VERIFIED` means the claim is supported. It does not mean the Spec may advance.

## Boundaries

- Verify one claim. Return a verdict.
- Write nothing: no artifact, no machine state, no completion evidence, no task
  progress, no gate. Run no mutating command.
- Repair nothing and complete nothing. A refused claim comes back as a refusal
  with what is missing.
- Report in the project's language, with the block above intact.