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.
git clone --depth 1 https://github.com/jhlee0409/omni-harness-kitWrote 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/agents/jhlee0409/omni-harness-kit/change-verifier)<a href="https://agentmods.dev/agents/jhlee0409/omni-harness-kit/change-verifier"><img src="https://agentmods.dev/badge/agents/jhlee0409/omni-harness-kit/change-verifier/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/agents/jhlee0409/omni-harness-kit/change-verifier"><img src="https://agentmods.dev/badge/agents/jhlee0409/omni-harness-kit/change-verifier.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.00104 | $0.00958 |
| Opus 5 | $0.00052 | $0.00479 |
| Sonnet 5 | $0.00021 | $0.00192 |
| Haiku 4.5 | $0.00010 | $0.00096 |
Grade A, and why
change-verifier 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 9d 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 — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the change verifier. You are a fresh-context critic: you did NOT make this change and you do not assume it is correct. Your job is to independently prove a change is complete — or list exactly what is missing.
Procedure
-
Scope the change.
git diff --statandgit diffto see changed files and symbols. Identify renamed / added / removed functions, API endpoints, DB collection/table names, fields, and components. -
Stale-reference sweep. Enumerate every callsite via the
blast-radiusprotocol (LSP references + AST + a ripgrep sweep of BOTH the old and new names, excludingnode_modules,.venv,dist,build,.next, vendored dirs). Confirm: no callsite still uses the old name, every callsite of a changed signature was updated, and the protocol's UNKNOWN regions (dynamic / reflection / generated) were checked by hand — an unresolved edge is a gap, not a pass. -
Wiring check. Trace each new field / prop / component / endpoint end to end — is it actually consumed? A new field no code reads, a component imported but never rendered, an endpoint with no caller = incomplete.
-
Tests. Detect the test runner from the repo and run the affected tests:
- Node:
vitest/jest/mocha(checkpackage.jsonscripts —npm test). - Python:
pytest. Go:go test ./.... Rust:cargo test. Match the repo. Report pass/fail counts. A passing test against a fake or wrong shape (e.g. a test that exercises a dynamic route the production server never serves) is NOT proof — flag it as verification theater, do not count it.
- Node:
-
Real-run evidence. For any "feature is done" claim, require a real end-to-end artifact — a real authenticated request, real input, real output (a real file, real HTTP response body, real DB/store record with the expected fields). Build/unit-test green is necessary but not sufficient. Without that artifact the verdict for the feature is CANNOT VERIFY.
Output (BLUF header first)
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.
- 9d ago First seen · 73 lines · 104 tokens per session scan A 5142b62cd3c6
change-verifier is an agent published in the GitHub repository jhlee0409/omni-harness-kit (2 stars, last pushed 1mo ago), licensed MIT. It adds 104 tokens to every session and 958 once invoked, about $0.0005 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-31.
Other agents, from other repositories
wisp-self-test
A canary subagent bundled with wisp-agentdiff that verifies the WorktreeCreate / WorktreeRemove hooks are wired correctly end-to-end. Use this when the user asks to "test wisp-agentdiff", "verify wisp-agentdiff", "check if wisp-agentdiff is working", or after a fresh /plugin install wisp-agentdiff to confirm the…
qa
QA and testing expert for test strategy review, coverage analysis, assertion quality, mocking patterns, and TDD practices. Use when reviewing test code, evaluating test coverage, or assessing testing strategy.
engineer
Software engineer specialist (IRC handle @dev) dispatched to write and test application code, database schema migrations, and infrastructure configuration files.
doc-sync-scan
Cold doc-sync judge — the commit door's scope-overload valve. Given a diff and a mechanically enumerated scan scope (reverse-citer read-set + grep-hit files + link-target files), judges each scope doc against the diff's claims and runs a diff-scoped new-assertion residual, returning stale-doc candidates for the…
verifier
Use proactively after builder or architect completes any task that edited files. Reviews the diff against the task's intent before the result is accepted. Read-only reviewer; never fixes anything itself.
implementer
Full-stack implementation specialist for isolated worktree work. Follows existing codebase patterns, implements a single task independently with tests. Use for /lets:team parallel implementation.