Reality Check
Compare an expected state with observable evidence, measure declared goals, or report native status. Select the requested question; a snapshot needs no invented completion claim. Return facts and gaps without selecting work. Neighbours: advice on a plan or change is Review; an acceptance verdict on a finished change is Validate.
Claim comparison
Enumerate every stated claim, including work that was never started, and give each its own disposition: confirmed (cite the evidence), gap (cite what is missing or contradicts it) or unverifiable (name the evidence that would settle it). The named failure mode is auditing only what the diff touched: a claimed item with no trace in the evidence is a gap, not something to leave out of the report.
- Read the exact claim and its source, and split it into its separate items.
- Inspect the relevant files, command outcomes and artifacts, separating confirmed behavior, concrete gaps, incomplete evidence and changed assumptions. Credit only what the evidence shows: a reported run without its output, behavior left to a default or another component, and a test that exercises code without asserting the claimed outcome are unverifiable, not confirmed. Name the missing evidence instead of resolving an untestable claim by assertion. For a claim that behavior is implemented, search the code behind it for pretend implementations: constant or hard-coded results, TODO or not-implemented branches, sample data, or test doubles outside test code. Trace each hit to its callers before classifying it. A placeholder that a production path reaches makes the item a gap; a double used only by tests, or code nothing calls, does not. A claim that work was pushed, merged, shipped or fixed in a named commit or pull request has its delivery settled by reachability in current remote state, not by a local ref, push output or saved status; whether the content is still present at the target head and does what is claimed is checked as above. Pushed means reachable from the named remote branch, or from the pull request's current head in its own head repository, forks included. Merged means reachable from the target branch the claim names, otherwise the default branch head, or a pull request merged with that branch as its base; a merge into another base does not confirm it. Shipped means present in what the repository's release policy names (a tag, published release or deployment), read from that source. Where squash or rebase broke ancestry, compare the content with the target rather than assume an equivalent commit. Check a supplied SHA or pull request number's form before it reaches a command.
- When asked about a plan, compare proposed scope with the original goal; additions that lack authority are scope escalation the report cannot approve. Repeated measurements reuse the same question and criteria; a changed question starts a different comparison.
- Return the ledger with checked and not-checked scope. Keep native tracker, Git, runtime, deterministic-check and semantic-judgment facts distinct.
textClaim: <the claim as stated, and where it came from> | # | Stated item | Disposition | Evidence, or what would settle it | |---|---|---|---| | 1 | <item> | confirmed / gap / unverifiable | <file:line, command output, artifact> | Checked: <what was inspected>. Not checked: <what was not>.
The ledger reports evidence; it carries no verdict, readiness call or PASS.
A quick answer is inline. A selected durable gap report uses
reality-check-report.v1: write reality-check-report.json under the caller's
chosen destination, default .agents/scratch/reality-check/<run-id>/, and check
it with this skill's scripts/validate-output.sh <report.json>. Record the
claim, evidence-backed finding kinds and the per-item dispositions in
coverage. The format permits no verdict, readiness or PASS field;
observations are not independent semantic judgment.
Establish the requested outcome
A request to check a stated claim (done, shipped, fixed, every item complete) against the evidence selects the claim comparison above without another question; so do explicit requests to measure declared goals or report native status. A bare readiness question with no claim and no settled purpose is ambiguous: ask once whether the caller wants advisory findings or an acceptance judgment, and wait. A claim audit is not acceptance and cannot substitute for Validate's fresh, author-distinct judgment. If acceptance is wanted, hand off and report a missing fresh reviewer as a gap, never as validation that occurred. Shared routing and handoff detail: advice or acceptance.
Health snapshot
For "is this repository healthy" or "do the checks pass", run the project's
own read-only checks: those declared in its instructions or CI configuration,
or found in its build files. Prefer a --check, dry-run or verify variant
when one exists. List any step that writes tracked files, publishes, deploys
or needs credentials as not run, with the reason. Record what you selected and
where it came from. Run each one separately and keep going after a failure so
later results are not lost.
Report each check as passed, failed, not run because the tool is unavailable,
or not determined because its output could not be captured, and take the result
from the exit status rather than from parsing the output. Name declared checks
you did not run. Do not fix anything, and do not fold the results into one
score that hides a failure.
Goal measurement
Running ao goals against the declared goals source, its derived snapshots and
what to return are in goals. Do not add, remove,
prioritize, migrate or repair goals, or turn a measurement gap into assigned work.
Native status
Reading the evidence store with ao status, and what a snapshot cannot show,
are in status. A recent artifact timestamp proves
evidence recency, not an active worker.
Boundary
Return the selected report or snapshot. This skill neither changes native state nor issues semantic PASS, repairs records, schedules or retries work. The documented goal snapshots and requested report/spec writes are its only output side effects. A native caller pursuing an authorized outcome uses these facts and continues its work; the reporting mode does not decide completion for it.
