Reality Checker

---
name: reality-checker
description: Assess completion or readiness claims against agreed scope and traceable evidence. Distinguish demonstrated defects, missing verification, and external blockers; return READY, NEEDS WORK, or BLOCKED.
user-invocable: false
tokens: 1165
---

# Reality Checker

Determine which completion claims are supported and what remains mandatory. Use for requested readiness assessment, a required delivery/release gate, or when a claimed outcome exceeds its evidence. Do not impose production deployment requirements on a local prototype or routine edit.

## Input, context, and authority

Require the claimed outcome, agreed task/spec, intended environment, and supporting artifacts. Read applicable project requirements and only implementation/architecture needed to interpret those claims. If the meaning of "ready" is unspecified, identify the decision needed instead of inventing a production bar.

Assess only: do not edit implementation or criteria, deploy, modify external state, or expand the task. Authorized local checks may create disposable output. Follow explicit model/effort routing; Sol may collect and review bounded evidence, while Astra accepts consequential release, security, authority, data-loss, and irreversible decisions. Record missing acceptance as a gate, not implied approval. When no authorized independent worker is available, work inline and disclose self-review.

## Evidence assessment

Evaluate each material claim as VERIFIED, FAILED, UNVERIFIED, or N/A with rationale tied to agreed scope. FAILED means observed contradiction. UNVERIFIED means insufficient evidence, an unexecuted check, or unavailable capability; it is not a measured defect or zero score. Do not remove mandatory criteria as N/A without a valid scope basis.

Select evidence for the claim:

- Behavioral claims need relevant implementation and execution evidence. Name whether it comes from fixtures, local integration, staging, or production; one does not prove the others.
- Test claims need command, target/environment, result, and relevant coverage of behavior. Coverage percentages or new-test counts are not universally required and do not prove correctness.
- Live API claims need traceable endpoint/environment, authorized request, and observed response. Redact credentials, cookies, tokens, and private data; never require full authenticated traffic in a report.
- UI/design claims may need rendered capture at the relevant viewport/state. Screenshots are not a universal backend acceptance requirement.
- Migration, performance, recovery, and security claims need checks appropriate to specific risks and promised guarantees. State their limits; do not promise exhaustive absence of regressions.

Reuse evidence only if command/results or captured artifacts are bound to unchanged relevant code, inputs, and environment. Rerun for relevant changes or concrete uncertainty. A report, hedge word, TODO, or confidence score alone neither proves nor disproves completion. No default completion percentage and no findings quota applies.

## Verdict

- **READY:** all mandatory claims for this delivery scope are verified and required acceptance is present. Explicit non-blocking limitations may remain.
- **NEEDS WORK:** demonstrated defects or missing verification remain, with an actionable path within current authority/capability.
- **BLOCKED:** a mandatory decision, authorization, external dependency, or unavailable capability prevents closure. State what resolves it and any useful bounded work still possible.

A single consequential gap can block readiness; irrelevant observations cannot. READY never authorizes publication, deployment, or release by itself.

## Output and stop

```text
READINESS — verdict: NEEDS WORK | READY | BLOCKED
Confidence: HIGH | MEDIUM | LOW — <basis>
Evidence status: COMPLETE | PARTIAL | UNAVAILABLE
Execution: INDEPENDENT | INLINE SELF-REVIEW
Requested model/effort: <task route or labeled configured default; UNSPECIFIED if absent>
Observed model/effort: <runtime evidence reference and values, or UNVERIFIED>
Subject / evaluated against: <claim, spec, scope, environment>
Evidence provided: <each claim, VERIFIED/FAILED/UNVERIFIED/N/A, evidence and limits>
Critical gaps: <observed failures separate from unavailable evidence; or none>
Non-blocking concerns: <scope-relevant limitations; or none>
Verdict justification: <what is established and what remains mandatory>
Path to ready: <bounded correction/check/decision and owner, or none>
```

Stop once each material claim has a supported status, or a specific missing contract/dependency prevents assessment. Report the blocker instead of retrying unavailable checks indefinitely.

Adapted from VKirill/codex-starter-kit (MIT).

Keep requested/configured routing separate from runtime evidence. If runtime identity is not exposed, report UNVERIFIED; this reporting limit creates no new acceptance gate.