Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/tzachbon/smart-ralphnpx agentmods add skills/tzachbon/smart-ralph/reality-verificationWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tzachbon/smart-ralph/reality-verification)<a href="https://agentmods.dev/skills/tzachbon/smart-ralph/reality-verification"><img src="https://agentmods.dev/badge/skills/tzachbon/smart-ralph/reality-verification/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/tzachbon/smart-ralph/reality-verification"><img src="https://agentmods.dev/badge/skills/tzachbon/smart-ralph/reality-verification.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00081 | $0.00872 |
| Opus 5.5 | $0.00032 | $0.00349 |
| Sonnet 5.5 | $0.00016 | $0.00174 |
| Haiku 4.5 | $0.00008 | $0.00087 |
Grade A, and why
reality-verification scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 111 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reality Verification
For fix goals: reproduce the failure BEFORE work, verify resolution AFTER.
Goal Detection
Classify user goals to determine if diagnosis is needed. See references/goal-detection-patterns.md for detailed patterns.
Quick reference:
- Fix indicators: fix, repair, resolve, debug, patch, broken, failing, error, bug
- Add indicators: add, create, build, implement, new
- Conflict resolution: If both present, treat as Fix
Command Mapping
| Goal Keywords | Reproduction Command |
|---|---|
| CI, pipeline | gh run view --log-failed |
| test, tests | project test command |
| type, typescript | pnpm check-types or tsc --noEmit |
| lint | pnpm lint |
| build | pnpm build |
| E2E, UI | Playwright MCP browser tools |
| API, endpoint | WebFetch tool |
For E2E/deployment verification, use MCP tools (Playwright MCP browser tools for UI, WebFetch tool for APIs).
BEFORE/AFTER Documentation
BEFORE State (Diagnosis)
Document in .progress.md under ## Reality Check (BEFORE):
## Reality Check (BEFORE)
**Goal type**: Fix
**Reproduction command**: `pnpm test`
**Failure observed**: Yes
**Output**:
FAIL src/auth.test.ts Expected: 200 Received: 401
**Timestamp**: 2026-01-16T10:30:00Z
AFTER State (Verification)
Document in .progress.md under ## Reality Check (AFTER):
## Reality Check (AFTER)
**Command**: `pnpm test`
**Result**: PASS
**Output**:
PASS src/auth.test.ts All tests passed
**Comparison**: BEFORE failed with 401, AFTER passes
**Verified**: Issue resolved
VF Task Format
Add as task 4.3 (after PR creation) for fix-type specs:
- [ ] 4.3 VF: Verify original issue resolved
- **Do**:
1. Read BEFORE state from .progress.md
2. Re-run reproduction command: `<command>`
3. Compare output with BEFORE state
4. Document AFTER state in .progress.md
- **Verify**: `grep -q "Verified: Issue resolved" ./specs/<name>/.progress.md`
- **Done when**: AFTER shows issue resolved, documented in .progress.md
- **Commit**: `chore(<name>): verify fix resolves original issue`
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 111 lines · 81 tokens per session scan A dd5607ae544b
reality-verification is a skill published in the GitHub repository tzachbon/smart-ralph (562 stars, last pushed 1mo ago), licensed MIT. It adds 81 tokens to every session and 872 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
verify-omnigent
Drive Omnigent the way a user does and prove a behavior with recorded evidence, using an isolated server, runner, and mock model plus a feature map of every user entry point. Load before reproducing a user-facing bug, before claiming a fix works, or when reviewing whether a change covered every surface (session vs.…
moai-ref-testing-pyramid
Test pyramid strategy, coverage targets, test patterns, and quality metrics reference. Agent-extending skill that amplifies manager-develop test-creation and quality-validation work with production-grade testing patterns. NOT for: production code implementation, architecture design, DevOps, security audits.
testing-blocks
Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.
moai-workflow-loop
Ralph Engine - Automated feedback loop with LSP diagnostics and AST-grep integration for continuous code quality improvement. Use when implementing error-driven development, automated fixing, or continuous quality validation workflows.
moai-workflow-testing
Use when writing tests, measuring coverage, or running characterization, performance, or PR-review QA. Comprehensive specialist combining DDD testing, characterization tests, performance profiling, and TRUST 5 quality-assurance validation.
webapp-qa
Perform scoped exploratory QA of a web application, reproduce defects, collect screenshots and console evidence, and deliver a prioritized report.