ground-truth

Verifies state-changing actions against fresh ground-truth snapshots before reporting success.

20|2|Updated May 16, 2026
One-click install
npx skills add https://github.com/reddb-io/red-skills --skill ground-truth-reddb-io
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ground-truth
Source: https://github.com/reddb-io/red-skills/tree/main/plugins/dev/skills/engineering/ground-truth
Command: npx skills add https://github.com/reddb-io/red-skills --skill ground-truth-reddb-io

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Agents often report a form submit, write, navigation, fix, or review verdict as successful based only on the action's own return value or a stale pre-action snapshot, producing verification hallucinations. This Skill enforces a claim → fresh ground-truth → confirm loop so every success report is backed by a post-action read from the source of truth. ## Core Features & Use Cases - Claim-first verification loop: State a checkable observable before acting, re-derive it from a fresh snapshot (a11y tree, DB query, file re-read, test re-run, API GET), then confirm or recant with the fresh read as citation. - Stale-ref validation: Detects references (DOM refs, row ids, line numbers) captured before a state change and forces re-resolution by stable identity such as role + name or primary key. - red-browser integration: Uses red-browser snapshot for token-cheap a11y-tree snapshots with numbered refs, monotonic snapshotIds, and console/network capture as browser ground truth. - Use Case: Inside /verify, after clicking a submit button, take a fresh red-browser snapshot and confirm the success banner node actually appeared before reporting the form submission worked. ## Quick Start Use the ground-truth skill to verify my last UI edit actually changed the target element by taking a fresh red-browser snapshot before reporting it done.

Frequently Asked Questions about ground-truth

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a browser action actually succeeded?▼

State the checkable observable first, then take a fresh red-browser a11y-tree snapshot after the action and confirm the observable against it. Never rely on the action's return value or a snapshot taken before the action.

What is a stale ref and how do I avoid acting on one?▼

A stale ref is a reference captured from an earlier snapshot that no longer points at the same element after a state change. Re-snapshot after every state change and re-resolve refs by stable identity like role plus name, not by position.

Does this verification loop work outside the browser?▼

Yes, the same claim → fresh read → confirm loop applies to DB writes, file edits, API mutations, code fixes, and review claims. Use the cheapest fresh read that proves the observable, such as a SELECT query, file re-read, or test re-run.

Why is 'no error' not enough to confirm success?▼

An exit code of 0 or missing error only means the action ran, not that the intended state changed. Without a fresh post-action ground-truth read, the claim is unverified and must be reported as such.

When should I use red-browser snapshots instead of screenshots?▼

Prefer red-browser a11y-tree snapshots when you need a token-cheap ground-truth read with numbered refs, a monotonic snapshotId for freshness, and console/network capture. Screenshots cost far more tokens for the same verification signal.