Verify Work

---
name: verify-work
description: "Use when checking whether work or a claim actually holds: running tests, builds, or the real path, and judging what the evidence shows, including failures and conflicting results."
---

# Verify Work

Determine what fresh direct evidence establishes about a specific claim at the boundary where it must hold.

The **Rules** below are binding; if one cannot be met, stop and say why. Everything else is **judgment**: follow its stated goal, and adapt when a different choice serves that goal better.

## Rules

- Verification establishes facts, not review judgment, authority, or permission to continue. A Supported claim permits judgment of the result; it does not establish a review Pass, close a Slice, or authorize delivery.
- Never encode a guess as an expected result. When expected behavior is unsettled or sources conflict, return the issue through [Workflow](../../skills/workflow/SKILL.md) or [Decision Gate](../../skills/decision-gate/SKILL.md).
- Run active checks (tests, reproductions, benchmarks, instrumentation) only when the current agreement covers them. Otherwise return the purpose, observer, expected evidence, and stop condition to Workflow and wait.
- Never rerun until unfavorable evidence disappears, and never change valid tests, implementation, Specs, policy, or acceptance merely to make a signal green. Preserve failures, contradictions, and partial or reduced-fidelity results.
- If a revised check establishes less than the original, the original claim stays Inconclusive unless other evidence establishes it at the required boundary; expose that limitation before acceptance rather than carry the stronger claim into the report.
- Missing evidence is not zero, safe, passed, or probably correct. Never invent a receipt or an earlier failing run that was not observed. If the user skips a check, leave the corresponding claim unverified.
- Base reports on actual assertions, outputs, and the state examined, not on test names or on the requested work phrased as accomplishments.

## Establish The Claim And Its Source

Goal: know exactly what is being claimed, where it must hold, and why it is expected, before choosing a check.

Identify the behavior or property, the required observing boundary, and the source of its expectation. Keep this compact when obvious; do not let an available test silently narrow a broader claim. Claims may concern behavior, a reported failure, structural validity, interfaces, integration, host lifecycle, installed artifacts, failure or recovery semantics, performance, or repository state.

Distinguish required acceptance from an optional stronger assertion. If evidence for an optional claim is unavailable, qualify or withdraw that claim rather than automatically add implementation. A required guarantee remains unresolved until supported or explicitly changed by its owner.

## Choose Sufficient Evidence

Goal: the smallest observation that could actually disagree with the claim, at the right boundary.

Use the smallest direct observation that can disagree with the claim. Before relying on an unfamiliar fixture for substantial dependent work, establish that it reaches the required observing stage and distinguishes the relevant wrong behavior. Reuse an adequate existing fixture; observer preparation is not a mandatory separate prototype.

For saved evidence, identify what code or artifact, check, configuration, and environment it examined, using existing outputs and source identities where available. Compare relevant later changes, including new files and generated output; HEAD alone does not identify an uncommitted candidate. Keep two facts separate: the observation occurred, and it applies to the current state. A later edit does not erase an earlier pass, and uncertain applicability does not certify the new candidate. Report missing identity or output rather than building a new evidence store. Reuse results whose applicability remains supported; rerun only affected evidence, and do not repeat checks merely because another activity or context began.

Use [Action Selection](../../skills/action-selection/SKILL.md) when several observers are plausible or the likely interaction is broad; Verify Work keeps the claim and interprets support. An already-selected focused check needs no extra selection.

Read the relevant reference before designing or selecting evidence:

- [Test Design](references/test-design.md) before designing or materially changing a behavior check, including regression or characterization coverage.
- [Integration Evidence](references/integration-evidence.md) when a claim depends on a registered callback or executor, host lifecycle, producer invocation, fallback protocol, installed package, or absence counter.
- [Browser Runtime Evidence](references/browser-runtime-evidence.md) for rendered UI, browser behavior, accessibility, networking, console state, visual output, or browser runtime performance.
- [Performance Evidence](references/performance-evidence.md) for latency, throughput, memory, CPU, bundle, query, rendering, capacity, or resource-regression claims.

Browser-performance claims need both browser fidelity and performance methodology. Loading a reference does not expand the required claim.

Passing tests do not prove behavior they do not exercise. Source inspection does not prove runtime execution; a helper call does not prove registration, native dispatch, or installed-package behavior; a happy path does not establish failure handling.

## Run Without Manufacturing A Signal

Goal: the observation reflects the candidate, not the harness or the schedule.

Before parallel checks, compare what each may write or remove. Serialize checks that share generated directories, caches, outputs, package roots, fixture state, ports, databases, or intentionally stale artifacts. Reproduce a concurrency-induced failure under a non-overlapping schedule before attributing it to production code.

For each covered check:

1. Run the complete selected observation.
2. Inspect output, exit status, assertions, and lower-level evidence that could contradict its summary.
3. Confirm that the intended path ran and the observer matched the claim.
4. Compare the observation with the independent expectation and its source.

Before revising a material assertion after failure, use Test Design to compare what the old and new checks establish. Repair source-backed observer or expectation errors.

Tests may be written before or after implementation as the task warrants; no test-first sequence is required, and test order is not evidence of validity. When a failure supports a diagnosis or regression claim, actually observe it at the relevant boundary.

## Classify Execution And Support Separately

Goal: never let a check's outcome stand in for what the evidence proves.

**Check result** describes the selected check's defined assertion:

- **Passed:** it executed validly and the assertion held.
- **Failed:** it executed validly and the assertion did not hold.
- **Error:** the observing mechanism or execution was invalid.
- **Unavailable:** the check could not be attempted safely or reliably.

A check may Pass by observing an expected rejection or failure.

**Claim result** describes what the evidence establishes:

- **Supported:** direct fresh evidence establishes the claim at its required boundary.
- **Contradicted:** evidence shows the claim is false.
- **Inconclusive:** available evidence cannot establish or refute it at that boundary.
- **Unavailable:** required evidence cannot currently be obtained safely or reliably.

A Passed check can leave the claim Inconclusive. A Failed check can expose a defect, an invalid expectation, an environment problem, or a source conflict; classify only the supported conclusion. Use [Diagnose Failure](../../skills/diagnose-failure/SKILL.md) when contradictions are unexplained or failure repeats.

## Return Evidence To Its Owner

Goal: the activity using the claim gets the observation and its limits, and nothing it did not ask for.

Return the observation and its limits to the activity using the claim. Distinguish implemented behavior, exercised checks, and supported claims, and list missing material cases even when the suite passes.

When answering a review Needs evidence item, preserve its pointer, claim, required observing boundary, previous evidence limit, and why the gap mattered, and return the result to the receiving agent for adjudication:

- Supported may settle the factual gap without settling the review.
- Contradicted may establish or invalidate a finding or expose a source conflict.
- Inconclusive or Unavailable leaves a material gap open.

Do not revise the independent report, adjudicate its findings, authorize correction, or select another review from verification.

## Report And Stop

For one straightforward Supported claim, report briefly:

```text
Claim @ required boundary: Supported ([check result]) by [evidence].
Proves:
Does not prove:
```

Use fuller reporting when evidence is adverse, conflicting, consequential, multi-boundary, or returning to adjudication:

```text
Review item: [when applicable]
Claim:
Required boundary:
Evidence:
Check result:
Claim result:
Proves:
Does not prove:
Required next evidence: [only when unresolved]
```

Do not manufacture empty fields or proof beyond the observation. When the result changes the work's direction or reaches its boundary, return to Workflow. Stop once the claim is classified and the supported next route or missing evidence is explicit.