Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add lahkiri/xeo-forge --skill live-verification-disciplinegit clone --depth 1 https://github.com/lahkiri/xeo-forgeWrote 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/lahkiri/xeo-forge/live-verification-discipline)<a href="https://agentmods.dev/skills/lahkiri/xeo-forge/live-verification-discipline"><img src="https://agentmods.dev/badge/skills/lahkiri/xeo-forge/live-verification-discipline/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/lahkiri/xeo-forge/live-verification-discipline"><img src="https://agentmods.dev/badge/skills/lahkiri/xeo-forge/live-verification-discipline.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00063 | $0.00237 |
| Opus 5 | $0.00032 | $0.00118 |
| Sonnet 5 | $0.00013 | $0.00047 |
| Haiku 4.5 | $0.00006 | $0.00024 |
Grade A, and why
live-verification-discipline 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 10d 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.
What it actually says
Xeo Forge treats an unverified claim of completion as a regression risk, not a milestone. When the agent believes a fix or feature is done, it first produces a live probe against the actual running system: a real provider API response for model claims, a raw DB row for persistence claims, a captured stream or request trace for UI claims. The probe result is attached to the work summary verbatim, including failures and partial results.
If a probe cannot run in the current environment (missing native modules, no network, offline provider), the agent states exactly which verification was skipped and marks the affected claims as "documented only, not live-verified" — the distinction travels with the claim wherever it is reported. A feature that cannot demonstrate its wiring across every layer it touches is reported as not finished, regardless of how complete the code looks.
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.
- 10d ago First seen · 9 lines · 63 tokens per session scan A 5f77459510f1
live-verification-discipline is a skill published in the GitHub repository lahkiri/xeo-forge (11 stars, last pushed 8d ago), licensed MIT. It adds 63 tokens to every session and 237 once invoked, about $0.0003 per session on Opus 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-08-30.
Other skills, from other repositories
copilotkit-contribute
Use when contributing to the CopilotKit open-source project — forking, cloning, setting up the monorepo, creating branches, running tests, and submitting pull requests against CopilotKit/CopilotKit.
pytest-suite
Write or extend the backend test suite following this project's conventions. Use when adding tests for a new service/route/repository, when coverage is missing, or when asked to test a feature. Knows the mocked-session + httpx AsyncClient setup so tests run with no database.
taiyi-dev
A software-development stage that implements planned tasks using test-driven development, or TDD: write a failing test, make it pass, then improve the code. It checks the task plan, dependencies, file boundaries, and required completion evidence.
taiyi-test
A project workflow skill for verifying an implementation and producing a TEST.md record. TDD means writing a failing test, implementing the change, and then making the test pass; this skill checks that process and other regression cases.
openlore-write-tests
Write and run real tests for a function or spec scenario after reading implementation and contract evidence. Use when asked to add, improve, or repair tests without stubs or placeholders.
repo-harness-check
Verification entrypoint for repo-harness workflow readiness. Runs workflow gates, task sync, contract checks, inspector, and migration dry-run before merge or release.