Evidence Claim Boundaries
Use this skill when a task produces or reviews evidence artifacts that could be
mistaken for proof of the real-world outcome. Verifiers, schemas, fixtures,
templates, summaries, and CI runs can make a future check stronger, but they do
not prove that the underlying live run, user-visible behavior, hardware path, or
deployment outcome happened.
Classify the Evidence
Name the evidence category before writing the claim:
readiness: tooling, verifier, schema, template, fixture, or docs hardening.proxy: logs, summaries, screenshots, traces, or generated reports that
describe another artifact.primary: the real artifact or behavior in the environment where it matters.human-gated: a primary artifact that requires a person to perform or observe
the live run.
If evidence is readiness or proxy, say what it prepares or checks. Keep the
completion claim open until primary evidence exists.
Write Bounded Claims
When reporting progress, include:
- The artifact changed or checked.
- The verifier or review path used.
- The exact outcome that is supported.
- The outcome that is not supported yet.
Prefer this compact form:
Readiness landed: <artifact/check>. Supports: <future claim it can verify>. Not claimed: <live/human/hardware/deployment outcome still missing>.
Human-Gated Outcomes
For manual or human-gated acceptance, stop at "ready for human attempt" until
the person-produced sanitized artifact exists. CI, fixtures, dry runs, templates,
or simulated inputs can prepare the path, but they cannot stand in for the
manual run.
When the human-gated artifact exists, report the required bundle:
- Same-session or same-environment identifier, if the claim depends on it.
- Sanitized primary artifact location or attachment.
- Verifier result or reviewer-safe summary.
- Residual missing rows, if any.
Review Checklist
Before marking an issue, PR, or task complete, ask:
- Is this primary evidence, or only readiness/proxy evidence?
- Does the wording name the real artifact still required?
- Could a reader mistake this for live, hardware, deployment, or human
acceptance?
- Are synthetic, fixture, dry-run, or CI-only artifacts clearly labeled as such?
- If the required artifact is unavailable, is the task reported as waiting,
blocked, or ready for human attempt rather than complete?
1---2name: evidence-claim-boundaries3description: Use when verifier output, schemas, fixtures, templates, CI, or readiness artifacts are being used to support live, human-gated, hardware, deployment, or completion claims.4---56# Evidence Claim Boundaries78Use this skill when a task produces or reviews evidence artifacts that could be9mistaken for proof of the real-world outcome. Verifiers, schemas, fixtures,10templates, summaries, and CI runs can make a future check stronger, but they do11not prove that the underlying live run, user-visible behavior, hardware path, or12deployment outcome happened.1314## Classify the Evidence1516Name the evidence category before writing the claim:1718- `readiness`: tooling, verifier, schema, template, fixture, or docs hardening.19- `proxy`: logs, summaries, screenshots, traces, or generated reports that20 describe another artifact.21- `primary`: the real artifact or behavior in the environment where it matters.22- `human-gated`: a primary artifact that requires a person to perform or observe23 the live run.2425If evidence is readiness or proxy, say what it prepares or checks. Keep the26completion claim open until primary evidence exists.2728## Write Bounded Claims2930When reporting progress, include:3132- The artifact changed or checked.33- The verifier or review path used.34- The exact outcome that is supported.35- The outcome that is not supported yet.3637Prefer this compact form:3839`Readiness landed: <artifact/check>. Supports: <future claim it can verify>. Not claimed: <live/human/hardware/deployment outcome still missing>.`4041## Human-Gated Outcomes4243For manual or human-gated acceptance, stop at "ready for human attempt" until44the person-produced sanitized artifact exists. CI, fixtures, dry runs, templates,45or simulated inputs can prepare the path, but they cannot stand in for the46manual run.4748When the human-gated artifact exists, report the required bundle:4950- Same-session or same-environment identifier, if the claim depends on it.51- Sanitized primary artifact location or attachment.52- Verifier result or reviewer-safe summary.53- Residual missing rows, if any.5455## Review Checklist5657Before marking an issue, PR, or task complete, ask:5859- Is this primary evidence, or only readiness/proxy evidence?60- Does the wording name the real artifact still required?61- Could a reader mistake this for live, hardware, deployment, or human62 acceptance?63- Are synthetic, fixture, dry-run, or CI-only artifacts clearly labeled as such?64- If the required artifact is unavailable, is the task reported as waiting,65 blocked, or ready for human attempt rather than complete?
selamy-labs